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SUMMARY 

Two highly maneuverable aircraft technology (Ili- 
MAT) remotely piloted vehicles were flown a to- 
tal of 26 flights. These subscale vehicles were of 
advanced aerodynamic configuration with advanced 
technology concepts such as composite and metal- 
lic structures, digital integrated propulsion control, 
and ground (primary) and airborne (backup) re- 
laxed static stability digital fly-by-wire control sys- 
tems. Extensive systems development, checkout, 
and flight qualification were required to conduct the 
flight test program. 

The design maneuver goal was to achieve a 
sustained 8-g turn at Mach 0.9 at an altitude of 
25,000 ft. This goal was achieved, along with the 
acquisition of high-quality flight data at subsonic 
and supersonic Mach numbers. Control systems 
were modified in a variety of ways using the flight- 
determined aerodynamic characteristics. The lli- 
MAT program was successfully completed with ap- 
proximately 11 hr of total flight time. 

INTRODUCTION 

The National Aeronautics and Space Administra- 
tion (NASA) has demonstrated advanced technol- 
ogy concepts through flight testing of two highly 
maneuverable aircraft technology (HiMAT) vehi- 
cles. These subscale remotely piloted research ve- 
hicles (RPRVs) were flown at the NASA Ames 
Research Center, Dryden Flight Research Facility 
(Ames-Dryden), at Edwards, California. The Ili- 
MAT vehicles included an advanced aerodynamic 
configuration and advanced technology concepts 
such as composite and metallic structures, a digital 
integrated propulsion control system (IPCS), and 
ground and airborne digital fly-by-wire control sys- 
tems. 

One of the primary features of the HiMAT 
vehicle was its construction from advanced ma- 
terials. In particular, the wing and canard 
were constructed from graphite-epoxy using a 
nonstandard ply layup technique. This tech- 
nique provided aerodynamically beneficial span- 
wise twist by aeroelastic tailoring designed to re- 
duce aircraft drag. In addition, the vehicles 
were designed to fly in a relaxed static stability 


(RSS) configuration to reduce trim drag. The design 
maneuverability goal was to achieve a sustained 8-g 
turn at Mach 0.9 at an altitude of 25,000 ft. With 
a ground-changeable wing leading edge (less cam- 
ber), the vehicle could also achieve sustained super- 
sonic flight. 

The RPRV concept, combined with the require- 
ments that no single failure result in loss of the ve- 
hicle and that the vehicle fly statically unstable, 
dictated a complex approach to the development 
of flight control systems, vehicle systems, fault de- 
tection and failure management, and systems flight 
qualification. Virtually all HiMAT systems were 
divided into two categories: primary and backup. 
Dual onboard microprocessor computers provided 
the key interfaces with the ground and various vehi- 
cle subsystems, and each was designed to provide for 
the safe return of the vehicle should the other fail. 
There were dual electrical and hydraulic systems, 
and dual flight control systems as well as redundant 
flight sensors. 

The HiMAT program was completed after a to- 
tal of 26 flights were flown with approximately 11 hr 
of flight time. The initial portion of the flight test 
program consisted of a series of flights in which both 
vehicles were ballasted in a stable or forward center- 
of-gravity configuration. The final 14 flights of the 
test program were flown in the relaxed static stabil- 
ity configuration. 

This paper presents the design features, flight 
qualification, and flight testing of the HiMAT digital 
primary and backup flight control systems for both 
the stable and relaxed static stability portions of the 
program. Included in the discussion are the fault de- 
tection and redundancy management methods de- 
veloped and simulation techniques required for final 
flight qualification of the control systems. Extensive 
flight test data are presented that illustrate partic- 
ular problems and the quality of the flight data. 

NOMENCLATURE 

Letter and Mathematical Symbols 

Where appropriate, parameters are referenced to a 
fuselage body axis system according to a right-hand 
sign convention. 
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a n normal acceleration, g 

c mean aerodynamic chord, 4.347 ft 

DAP pilot’s lateral stick displacement, in 

DEP pilot’s longitudinal stick displace- 

ment, in 

DRP pilot’s rudder pedal displacement, in 

g acceleration due to gravity, 

32.174 ft/sec 2 
h altitude, ft 

K system gains (units as required) 

M Mach number 

p roll angular rate, deg/sec 

q pitch angular rate, deg/sec 

q dynamic pressure, lb/ft 2 

r yaw angular rate, deg/sec 

s Laplace transform operator, rad/sec 

V c calibrated airspeed, knots 

a angle of attack, deg 

/ 3 angle of sideslip, deg 

S a aileron deflection, deg; 

<$a = (<5aL - <5aR.) 

6 C canard deflection, deg; 

f*c = (<5cL + £ c r)/2 
6 e elevator deflection, deg; 

<!>e = (^eL + ^eR)/2 

6 r rudder deflection, deg; 

= (<5rL + ^rR)/2 

6 V elevon deflection, deg; 

fiy “ (^vL + ^ V r)/2 
<5 va differential elevon, deg; 

<?>va = ($vL “ <5 V r) 

<5 a l left aileron deflection, deg 

<5 aR right aileron deflection, deg 

S c l left canard deflection, deg 

£ cR right canard deflection, deg 

<5 e L left elevator deflection, deg 

tf eR right elevator deflection, deg 

S r l left rudder deflection, deg 

^ rR right rudder deflection, deg 

left elevon deflection, deg 
<5 vR right elevon deflection, deg 

Abbreviations 

ADC analog-to-digital converter 

ADI attitude direction indicator 

AGL above ground level 

AIDS aircraft interrogation and display 

system 


ARI aileron-to-rudder interconnect 

ASE aeroservoelastic 

DCS backup control system 

CASH computation and simulation of 

HiMAT 

CRT cathode ray tube 

CSMC computer select mode control 

DAC digital-to-analog converter 

DPM degraded primary mode 

EGT exhaust gas temperature 

EPROM erasable programmable read only 

memory 

FTE flight test engineer 

FTIS flight test instrumentation system 

FTMAP flight test maneuver autopilot 

HiMAT highly maneuverable aircraft technology 

ILS instrument landing system 

10 input-output 

IPCS integrated propulsion control system 

KARI aileron-to-rudder interconnect gain 

KBQ onboard fixed rate gain 

MAC mean aerodynamic chord 

MCWP master caution and warning panel 

MDS microprocessor development system 

PCM pulse code modulation 

PCS primary control system 

RAM random access memory 

RPRV remotely piloted research vehicle 

RSS relaxed static stability 

SAE servoactuator electronics 

TM telemetered 

HiMAT VEHICLE 
DESCRIPTION AND 
OPERATIONAL PROCEDURE 

The HiMAT vehicles were remotely piloted, 0.44- 
scale versions of an envisioned full-scale aircraft. 
The overall vehicle configuration (fig. 1) was charac- 
terized by a swept wing with a close coupled canard. 
Overall vehicle dimensions are shown in figure 1. 
The five pairs of aerodynamic control surfaces are 
shown in figure 2. Table 1 presents the average an- 
gular surface rate capability, full surface travel po- 
sitions, and control mode function. The surfaces 
include the twin all-movable boom-mounted rud- 
ders which deflected symmetrically for yaw control 
and asymmetrically (toe-in) for speed-brake con- 
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trol. The elevator was used for pitch control, the 
elevons for pitch and roll control, and the ailerons 
for roll control. Later in the program, the ailerons 
were mechanically locked and only elevons were 
used for roll control. The canard flaps had the capa- 
bility of providing pitch and sideforce control; how- 
ever, no attempt was made to mechanize them in 
this fashion. 

The vehicle gross weight was approximately 
3501 lb with 659 lb of fuel. Each vehicle was pow- 
ered by a J85-21 turbojet engine rated at 5004 lb 
sea level static thrust. The engine was equipped 
with a nine-stage, variable-geometry axial compres- 
sor, a two-stage turbine, afterburner, and variable- 
area exhaust nozzle. Engine control was provided 
through an IPCS resident in the backup onboard 
computer. For additional details, see Bayati (1976) 
and Baer-Riedhart (1981). 

In keeping with the ground rule that no single 
failure should cause loss of the vehicle, dual electri- 
cal and hydraulic systems were implemented. These 
dual systems were designated primary and backup. 

The HiMAT vehicle primary electrical power 
was supplied by an engine-driven dc generator. In 
the event of a primary electrical system failure (en- 
gine, generator) backup power was supplied by a 
35-V silver-zinc battery. A 32-V transition battery 
provided electrical power to the computers during 
the transition from generator to backup power. 

Primary hydraulic power was supplied by an 
engine-driven pump. In the event of a primary hy- 
draulic system failure, an electrically driven pump 
supplied power to the backup hydraulic system. The 
electrically driven pump operated continuously in a 
no-load condition until a primary hydraulic failure 
was detected, in which case the backup hydraulic 
system was engaged. 

There were no single points of contact between 
the primary and backup hydraulic systems other 
than the dual tandem actuators used for the elevons 
and rudders. In these actuators, the systems were 
separated by dual seals. If a primary hydraulic 
failure was detected, airborne logic switched out 
the simplex canard, aileron, and elevator servoac- 
tuators, and they were commanded to a predeter- 
mined locked position (table 1). When a transfer to 
backup control occurred, the dual elevon and rud- 


der servoactuators switched to the backup hydrau- 
lic system. 

Operationally, the HiMAT vehicles were carried 
aloft under the right wing of a specially modified 
B-52 aircraft and were launched at approximately 
45,000 ft at Mach 0.68. Typical missions were ap- 
proximately 30 min. The pilot, in a fully instru- 
mented fixed-base ground cockpit, flew the vehicles 
through various research maneuvers using conven- 
tional fighter aircraft controls. Control of the ve- 
hicle was maintained through the ground comput- 
ers and uplink system. Aircraft response parame- 
ters were downlinked to the ground station and dis- 
played to the pilot. A flight engineer, next to the 
cockpit, assisted the pilot in the overall conduct of 
research maneuvers and navigation tasks through- 
out each flight. NASA ground radar tracked the ve- 
hicles and supplied the ground station with ground 
track, backup airspeed, and altitude information. In 
the event of certain ground or airborne failures, a 
backup flight control system could be engaged and 
flown from either the ground or the back seat of 
an airborne chase plane, and the aircraft could be 
guided to an emergency landing. The vehicles were 
equipped with landing skids for horizontal landing 
on Rogers dry lakebed. The landing runways were 
about 15,000 ft long and improved for about 150 ft 
on both sides of the centerline. Typical slide-out 
distance was approximately 4500 ft. 

HiMAT SYSTEMS 

DESCRIPTIONS 

Systems Overview 

In the description of the HiMAT vehicle systems, it 
is difficult to describe any one system independent of 
another owing to the requirement that both ground 
and airborne systems work in concert. 

Under normal research flight-test conditions, 
the vehicles were flown via the primary control sys- 
tem (PCS). The PCS control laws resided in the 
ground-based Varian V-73 computer (Varian Asso- 
ciates, Inc., Palo Alto, California) in the RPRV fa- 
cility with the ground-based cockpit. In the event 
of certain critical airborne or ground failures, trans- 
fer from PCS to the backup control system (BCS) 
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was usually automatic but manual transfer was pos- 
sible. The BCS control laws were resident in the 
backup computer aboard the vehicle. Control of 
the BCS was via discrete signals from either the 
ground-based cockpit or from the TF-104G chase 
aircraft. Command paths, and uplink and downlink 
telemetry signals are shown in figure 3. All critical 
parameters input to the PCS were downlinked at 
220 Hz. These signals included the three axis angu- 
lar rates, normal and lateral acceleration, angle of 
sideslip, and angle of attack. Less critical parame- 
ters such as air data were downlinked at the lower 
rate of 55 IIz. Commands to the vehicles were up- 
linked at a single rate of 53.3 Hz. 

Ground Systems 

Downlink Receiving Station 

Most computer-processed data to be down- 
linked were passed from the primary onboard com- 
puter to the flight test instrumentation system 
(FTIS) for transmission to the ground as a pulse- 
code modulation (PCM) data stream at 220 Hz. 
The ground station then received and decommu- 
tated the data into usable data words in counts. 
All these data were available to the Varian V- 
77 computers. The decommutation station also 
passed data directly to the pilot’s cockpit indicators 
for display. 

V-77 Computer 

The V-77 computer performed the necessary 
formatting of the vehicle sensor signals and trans- 
ferred these data to the V-73 PCS computer. The 
V-77 also decoded a set of downlinked discrete sig- 
nals to indicate status and health of various onboard 
vehicle systems. These signals were displayed to 
ground personnel by lighting a master caution and 
warning panel. 

Pilot’s and Flight Test Engineer’s 

Station 

Figure 4 shows the cockpit instrument array, 
left console, and the BCS discrete command panel 
on the right console. Cockpit instrument displays 
included a forward-looking video monitor (used pri- 
marily for landing approach), attitude direction in- 
dicator (ADI), radar altimeter (0 to 5000 ft), baro- 


metric altimeter, airspeed and Mach indicators, al- 
titude rate, engine rpm, fuel flow, fuel quantity, and 
exhaust gas temperature (EGT). Also included were 
the computer select mode control (CSMC) box and 
pulse panel. 

The pilot’s interface to the PCS was through 
standard fighter aircraft three-axis proportional 
controls consisting of a throttle lever, stick, and rud- 
der pedals. The speed-brake switch was provided 
on the top of the throttle lever. The stick and rud- 
der pedal force and displacement characteristics are 
presented in table 2. 

The pilot’s interface to the BCS was through 
the BCS discrete command switches on both the 
right and left consoles. The climb-dive, turn com- 
mand switch was on the right with the other mode 
command switches. The speed increase-decrease 
command switch was on the left console. The com- 
mands from these switches were transmitted di- 
rectly to the uplink encoder. Similar discrete panels 
were in the rear cockpit of the TF-104G chase air- 
craft. No HiMAT vehicle telemetry data were pro- 
vided to the F-104; therefore, control and guidance 
from the chase aircraft was visual only. 

The flight test engineer (FTE) communicated 
with the pilot to assist with navigation, checklist 
and emergency procedures, pulse panel test inputs, 
system gain changes, and landing energy manage- 
ment. The pilot and the FTE navigated using a 
radar-driven plot board showing ground track posi- 
tion. Energy was managed during landing approach 
when radar-driven glide slope was displayed on a 
plot board. Pulse panel inputs were initiated by the 
FTE and consisted of preprogrammed computer- 
generated control commands used to excite the air- 
craft motions independent of the pilot. System gain 
changes were usually reduced prior to pulse panel 
command inputs. Management of these tasks by 
the FTE greatly reduced pilot workload. 

Control Law, Maneuver, and 

Navigation Computers 

Three separate computers (fig. 3) were used to 
perform the PCS control law, maneuver autopilot, 
and navigational computational functions in a nor- 
mal mission. These computers were Varian V-73A, 
V-73B, and V-72 computers, respectively. 
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Vehicle downlinked sensor signals, processed 
through the V-77 computer, were combined with 
the pilot’s stick and throttle command inputs, from 
the cockpit, in the V-73A PCS control law com- 
puter. The PCS command signals would then be 
generated and uplinked to the vehicle. The V- 
73A computer was synchronized at 53.3-IIz frame 
rate to correspond to the fixed telemetered up- 
link rate. In addition to the PCS control law, the 
V-73A computer also performed air data calcula- 
tions (Mach number, altitude, altitude rate, air- 
speed, and dynamic pressure) for display in the 
ground cockpit. Some failure detection algorithms 
were also mechanized. In addition to the real- 
time in-flight computations performed by the V- 
73A, this computer was used to automate a sys- 
tematic vehicle preflight program that tested all in- 
put and output interface parameters both statically 
and dynamically. 

To assist in the acquisition of high-quality 
data, a flight test maneuver autopilot (FTMAP) 
control law was mechanized in a V-73B com- 
puter (Duke and others, 1986). The FTMAP 
was designed to provide precise, repeatable con- 
trol of the HiMAT vehicle during certain pre- 
scribed maneuvers. The FTMAP operated as a 
non-flight-critical outer-loop controller in conjunc- 
tion with the PCS. During FTMAP operation, 
the FTMAP computer (fig. 5) replaced the nor- 
mal pilot command inputs to the V-73A PCS com- 
puter. In addition to the FTMAP control law, 
the V-73B computer passed to the cockpit ADI 
the landing guidance information generated in the 
V-72 computer. 

The V-72 computer received and decoded 
tracking radar data and computed vehicle ground 
track information for display to the ground pilot. 
In addition to generating ground track information, 
the V-72 computed a quasi-instrument landing sys- 
tem (ILS) glideslope and localizer for display in the 
cockpit during approach and landing. 

The characteristics and functions of the V-77, 
V-73 and V-72 ground computers are summarized 
in table 3. 

Uplink Encoder 

The PCS command signals, from the V-73 com- 
puter, were combined with the cockpit discrete sig- 


nals in the uplink encoder prior to transmission to 
the vehicle. The encoder was formatted to send four 
16-bit words per frame at a rate of 106.6 frames/sec. 
Two different frames were alternately sent for a to- 
tal of eight 16-bit words updated 53.3 times/sec 
(frame rate of 18.76 msec). The uplink data for- 
mat is shown in figure 5. The first four words ad- 
dressed vehicle decoder number one, and the last 
four words addressed vehicle decoder number two. 
The first 10 bits of each word were available only 
to the primary onboard computer and were desig- 
nated proportional data. These proportional chan- 
nels represented the PCS interface to the vehicle 
aerodynamic surfaces and throttle. The last 6 bits 
of each word were designated as manual command 
discretes and were hardwired directly to the encoder 
from cockpit switches. These discretes represented 
the pilot’s discrete interface to the onboard BCS and 
other vehicle systems. 

Airborne Systems 

Figure 6 presents an overview of the integrated 
airborne systems. This figure shows the major 
components of the airborne systems and includes 
the following: uplink receivers-diversity combiner- 
decoders, airborne computers, flight sensors, ser- 
voactuator electronics (SAE) box, and FTIS. 

Uplink Receivers-Diversity 

Combiner-Decoders 

Dual receivers-decoders received the uplink sig- 
nal and provided the command input interface to 
the dual onboard computers. The PCS required 
both receivers-decoders to be operational. If either 
decoder failed, an automatic transfer to BCS re- 
sulted. Early in the HiMAT program, there were 
frequent automatic transfers from PCS to BCS be- 
cause either or both receivers-decoders received in- 
adequate uplink signals as a function of vehicle atti- 
tude. To eliminate these nuisance transfers to BCS, 
a diversity-combining concept was used in the hard- 
ware to provide uninterrupted telemetry coverage 
(Harney, 1981). The diversity combiner continu- 
ously combined the output signals of the dual re- 
ceivers so that regardless of the orientation of the 
airplane with respect to the transmitting antenna, 
the best signal was available for all uplink com- 
mands. Diversity-combining hardware was installed 
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in vehicle number one following the third flight, and 
nuisance transfers to BCS were virtually eliminated. 
Vehicle number two was modified in the same way. 

Airborne Computers 

The dual onboard digital computers (fig. 7) 
were designed and built especially for the Hi- 
MAT vehicles. These computers formed the heart 
of the entire HiMAT system and each was de- 
signed to control the vehicle should the other fail. 
All critical onboard flight systems were controlled 
by these computers. These two computers were 
based on Intel 8080 microprocessors (Intel Corpo- 
ration, Santa Clara, California) and operated asyn- 
chronously with respect to each other but had iden- 
tical computational and memory capacities. The 
computers were designated primary and backup, 
with different resident software and input-output 
interfaces. Each computer contained 22,528 bytes 
(8 bits) of erasable, programmable, read-only mem- 
ory and 1024 bytes of random access memory. Both 
computers were programmed entirely in 8080 as- 
sembly language and packaged in a common chassis 
with separate circuit card sets and connectors. The 
dual computer chassis weighed 40 lb and had a vol- 
ume of 1198 in 3 . 

The principal functions of the primary com- 
puter were as follows: (1) uplink data processing, 
(2) downlink data processing, (3) failure detection 
for the computers, flight sensors, servoactuators, 
and power system (for both backup and primary 
flight control modes), and (4) backup IPCS. The 
principal functions of the backup computer were (1) 
uplink data processing, (2) primary IPCS, and (3) 
BCS control laws. 

Computer interfaces with aircraft systems con- 
sisted of three types — digital, discrete, and analog. 
Each of the computers communicated with the out- 
side world via the telemetry uplink and downlink 
systems, and with each other via an intercom. For 
additional details on the HiMAT airborne comput- 
ers, see Myers and others (1981). 

Flight Control Sensors 

Seven redundant flight-critical control system 
sensor sets were necessary to provide the HiMAT 
with the fail-safe operational capability. Five of the 
sensor sets were triplex and two were duplex. The 


seven sensor sets included the triplex three-axis an- 
gular rate gyros, normal and lateral accelerometers, 
and the duplex air data system(static and impact 
pressures). Air data rates were determined by an 
analog differentiation of the air data signals. A sin- 
gle sensor of each set was designated the backup to 
the BCS. 

A simplex vertical gyro (all-attitude gyro) and 
radar altimeter were provided, however, they were 
not flight control system critical. The vertical gyro 
provided vehicle attitude information to the pilot’s 
ADI and to a direction cosine algorithm in the BCS 
code. The radar altimeter provided data to the pi- 
lot at altitudes below approximately 5000 ft in the 
landing approach situation and was a key input to 
the BCS in the automatic landing mode, however, 
the BCS could be used to land the vehicle even if 
this instrument failed. 

Servoactuator Electronics Box 

The servoactuator electronics (SAE) box pro- 
vided the interface between the onboard computers 
and the control surface servoactuators and the en- 
gine nozzle. The SAE box functions included elec- 
trically closing all servo loops to the actuators, re- 
ceiving all actuator commands from the computers, 
and feeding back all actuator positions to the com- 
puters. Another major function was the failure de- 
tection of the elevon servoactuator system, which 
was detected faster in hardware than software. If 
a failure was detected, it was communicated to the 
primary computer (this is discussed in the duplex 
actuator failure management section). 

Flight Test Instrumentation System 

To complete the onboard systems, the flight 
test instrumentation system (FTIS) handled and 
processed all data to be downlinked into a digital 
PCM data stream. Inputs to the FTIS included 
both direct sensor (analog) and onboard computer 
(digital) inputs. Select signals were downlinked di- 
rectly through the FTIS and also through the on- 
board computer. Onboard computer data to be 
downlinked were processed through the downlink 
processing routine. This routine processed and for- 
matted eighteen 10-bit proportional parameters and 
seven 10-bit discrete words. Also included in this 
routine were midvalue selection of the triplex sen- 
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sors, synchronization logic, and the packing of vehi- 
cle status and failure indication discretes. The PCM 
signal to be downlinked was input to dual transmit- 
ters to be telemetered to the ground at 220 Hz. 

CONTROL SYSTEMS 
DESCRIPTIONS 

Systems Overview 

The design goal of the HiMAT was that it should 
be capable of a sustained 8-g turn at Mach 0.90 at 
an altitude of 25,000 ft. To achieve this transonic 
maneuver performance goal, it was required that 

1. the vehicle be ballasted to an aft center-of- 
gravity condition to reduce trim drag and 

2. the wings be aeroelastically tailored to pro- 
vide favorable spanwise twist for drag reduction. 

The combination of vehicle aft center of gravity 
and aeroelastically tailored wings resulted in trailing 
edge down elevator and elevon trim with favorable 
wing twist at the specified design point. The aft cen- 
ter of gravity resulted in a longitudinal static margin 
of 10-percent negative at low angles of attack which 
increased to 30 percent at high angles of attack at 
low subsonic Mach numbers. These negative static 
margins placed unusual demands on the develop- 
ment of both the ground and airborne active con- 
trol systems. Owing to the high-risk nature of such 
an approach, the HiMAT program was conducted in 
two phases. The first phase was a relatively conser- 
vative approach with the vehicles ballasted in a for- 
ward center-of-gravity or stable configuration. The 
second phase was with the vehicles ballasted at a 
mid or aft center of gravity or RSS configuration. 
This approach allowed the accomplishment of the 
initial objectives and provided quantitative data for 
the continued development of the RSS control sys- 
tems. The disadvantage of this approach, however, 
was that the development of both stable and RSS 
control laws was required. 

Stable Control Systems 

The basic design considerations used in the de- 
velopment of the ground-based PCS and air- 
borne BCS were to provide adequate flight con- 
trol over the entire flight envelope and to pro- 


vide systems that would ensure completion of all 
program objectives. 

Stable Primary Control System 

The stable PCS was a full- authority three-axis 
rate damper system that commanded the eleva- 
tors and elevons for pitch control, the elevons and 
ailerons for roll control, and the rudders for yaw con- 
trol and drag modulation. Petersen (1979) presents 
additional details of the stable PCS. 

The HiMAT stable PCS longitudinal control 
law is shown in figure 8. The pitch rate feedback sig- 
nal passed through a pilot-switchable gain and was 
summed with prefilter pitch stick input. The com- 
bined signal was multiplied by a gain factor sched- 
uled as a function of static pressure and summed 
with a filtered angle-of- attack feedback signal. Used 
as an angle-of-attack inhibiting device, the angle- 
of-attack feedback signal commanded a nose down 
input whenever the vehicle’s angle of attack ex- 
ceeded 8°. The total-longitudinal command drove 
both the elevators and the symmetric component of 
the elevons. A launch mode input was implemented 
that inserted a nose down bias command during 
the launch sequence to ensure separation from the 
B-52 aircraft. Fader elements were implemented in 
the command paths to provide synchronization of 
the PCS uplink commands to the control surface 
positions while in the backup mode, and minimiza- 
tion of surface transients during a transfer from 
BCS to PCS. The final elevon and elevator com- 
mands were then summed with auxiliary input sig- 
nals controlled from a cockpit-mounted pulse panel 
prior to uplink output. The pulse panel inputs were 
used to excite the aircraft for the extraction of sta- 
bility derivatives. 

The lateral-directional control laws of the sta- 
ble PCS are shown in figure 9. The roll rate feed- 
back signal was summed with the filtered roll stick 
input to form the basic roll command. The roll 
rate gain and roll stick gearing were scheduled as 
functions of dynamic pressure and Mach number, 
respectively. The roll command controlled both 
the aileron and asymmetric elevon commands at 
a ratio determined by the aileron command gain. 
The rudder command consisted of the combination 
of rudder-pedal position and high-passed yaw rate 
multiplied by a gain scheduled with dynamic pres- 
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sure. Pilot-switchable gain functions were imple- 
mented for both the roll and yaw rate feedbacks. 
The faders and pulse panel inputs were used for the 
same functions described previously. 

Throttle position in the cockpit was passed 
through a nonlinear limiting function forming the 
throttle uplink command (fig. 10). Drag was modu- 
lated by deflecting the rudders asymmetrically trail- 
ing edges outboard as speed brakes. Speed brake 
authority was limited to 5° on each surface and was 
controlled using a throttle mounted discrete switch 
that activated an integrator within the primary con- 
trol laws (fig. 11). 

During the conduct of the stable phase of the 
flight-test program, several stable control system 
evaluations were conducted in support of the RSS 
phase. These evaluations included (1) roll con- 
trol with only differential elevon (ailerons locked), 
(2) evaluation of an aileron-to-rudder interconnect, 
and (3) lateral acceleration feedback to the rudders. 
Because the PCS was coded in FORTRAN, these 
modifications to the basic stable PCS were relatively 
easy. Simple discrete switches were used to activate 
each function for evaluation. Additional details of 
these evaluations are presented in the flight data 
section of this report. 

Stable Backup Control System 

The BCS was designed to recover control of 
the vehicle from unusual or extreme attitudes, pro- 
vide well- controlled vehicle dynamics throughout 
the flight envelope, and provide adequate control 
modes and vehicle stability to land at a selected 
site under control of either the ground or airborne 
controller. Failure in any one of a variety of pri- 
mary systems would normally result in an automatic 
transfer to BCS. Table 4 lists failures that would re- 
sult in automatic transfers to BCS. 

To ensure BCS versatility, a variety of auto- 
matic modes was implemented. Table 5 presents 
a list of the seven major modes mechanized in the 
BCS. Further, the BCS was required to command 
the vehicle to orbit at a specified altitude even in the 
absence of uplink or downlink carrier signals. All 
commands into the BCS were discrete: there were 
no proportional commanded inputs. Internal logic 
was used extensively for mode switching and con- 
trol and keyed upon these discrete commands. The 


basic BCS loop structure provided inner-loop stabi- 
lization functions at 100-Hz execution rate, outer- 
loop command functions at 50-Ifz execution rate, 
and less time-critical functions, such as some gain 
schedules, at 10-Hz execution rate. Further discus- 
sion of the BCS is presented in the RSS BCS sec- 
tion. Ivempel (1982) presents additional details on 
the BCS. 

Degraded Primary Mode 

Under certain failure conditions, such as engine 
failure, it was more desirable to retain proportional 
control rather than to be limited to discrete com- 
mands through the BCS. The pilots felt that pro- 
portional control would provide more precise control 
of the vehicle and should be retained if possible. The 
degraded primary mode, therefore, was mechanized 
as a subset of the normal PCS control law. The 
degraded primary mode (DPM) was ground-pilot 
selectable in the event of certain airborne failures, 
such as engine failure. In DPM the pilot retained 
his proportional stick, rudders, and throttle com- 
mands. The DPM control law was resident in the 
V-73A computer. When the DPM was selected, the 
vehicle backup systems were activated just as they 
would be had a transfer to BCS occurred, that is, 
elevator locked, elevon active for pitch and roll con- 
trol, rudder for yaw control, and backup electrical 
and hydraulic power active. 

Integrated Propulsion Control System 

The IliMAT engine was totally under control 
of the onboard computers. The primary IPCS con- 
trol law resided in the backup computer, and the 
backup IPCS was resident in the primary computer. 
The primary IPCS was mechanized in the backup 
computer owing to the memory limitations in the 
primary computer. The IPCS emulated the con- 
ventional J85-21 engine mechanical controls, but it 
also provided additional control modes not found in 
standard engines. 

The IPCS concept was based on the reten- 
tion of most of the conventional engine control 
hardware and allowed the implementation of flight- 
propulsion control coupling, high and normal en- 
gine stability margin operating modes, and rapid 
and normal thrust response modes through the 
computer program. For additional details on 
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the IPCS, see Bayati (1976) and Baer-Riedha.rt 
(1981). Table 6 lists the IPCS commands and 
the engine feedback signals for both PCS and 
BCS operation. 

In the primary IPCS, the engine was operable 
in either a normal or combat mode and at a high 
stability setting. In the normal mode, the engine 
operated in a conventional manner. In the combat 
mode, the rate of thrust response was significantly 
greater than that of a standard engine. The engine 
rotor speed was maintained at near intermediate 
power for all settings, and dry thrust modulation 
was achieved by varying the exhaust nozzle. The 
high-stability mode provided operation of the en- 
gine at a lower exhaust gas temperature, resulting 
in an increased stall margin compared to a stan- 
dard engine. 

The engine was controlled in PCS from the 
ground cockpit via the proportional throttle and 
discrete switches for the various engine operating 
modes. Cockpit discrete switches included (1) en- 
gine igniter, (2) combat mode, (3) nozzle override, 
(4) high stability, and (5) throttle reset. Throttle 
reset was used when some fault indication automati- 
cally selected the secondary throttle system. Throt- 
tle reset was used to reselect primary throttle when 
the fault was cleared. 

Throttle commands in BCS were generated 
based on prescribed airspeed schedules that were 
a function of the BCS operating mode. In BCS the 
engine was limited to dry power operation with ei- 
ther high or normal stability mode, depending on 
which had been selected prior to transfer. Com- 
bat mode and afterburner operation were inhibited 
in BCS. 

Relaxed Static Stability Control 
Systems 

The basic design considerations used in the RSS 
control systems were the same as those for the sta- 
ble control systems, that is, to provide adequate 
flight control over the entire flight envelope and 
to provide systems that would ensure completion 
of all program objectives. The RSS control sys- 
tems were designed for the 10-percent aft center- 
of-gravity configuration; however, operational con- 
siderations again dictated a more conservative ap- 


proach and the vehicle was flown only at 5-percent 
aft configuration. 

Longitudinal RSS PCS 

Development of a ground-based primary flight 
control system for a statically unstable vehicle 
proved difficult at best. Significant time delays 
from airborne sensor input to surface commands ex- 
isted. Figure 12 presents significant signal paths, 
using the pitch rate signal input and the elevators 
and elevons as outputs. Delays in each element of 
the control loop were analyzed and included (1) 
sensor filter delays, (2) telemetry downlink time, 

(3) telemetry ground data formatting and transfer, 

(4) V-77 and V-73 computer processing times, (5) 
uplink command delays, (6) onboard uplink receiv- 
ing and computer processing times, and (7) servoac- 
tuator system delays, to complete the loop. Total 
system time delays from sensor input to servoactu- 
ator surface command input were found to be ap- 
proximately 50 to 60 msec. Delays of this magni- 
tude in pitch rate proved unacceptable for the RSS 
configuration. 

The solution to the problem of excessive time 
delays was to include aboard the vehicle a com- 
plementary fixed gain pitch rate feedback to the 
elevons and elevators that provided significantly less 
than the 50 to 60 msec time delay that existed 
with the ground-based PCS. The mechanization of 
the onboard pitch rate feedback was through the 
primary computer, synchronized with the PCS up- 
linked pitch rate command, but with a significantly 
decreased time delay from sensor input to command 
output (see fig. 12). Pitch rate sensor input to 
the primary computer occurred between 1.0 and 
1.2 msec prior to being input to the downlink data 
stream routine. The downlink data routine received 
the pitch rate input and was executed at 220 Hz, 
or every 4.54 msec. This routine then passed the 
pitch rate information to the uplink decoder rou- 
tines (decoder 1 for elevons and decoder 2 for el- 
evators) through the computer, circumventing the 
ground loop. This information was then multiplied 
by the onboard pitch rate gain (KBQ) and summed 
with the uplinked pitch rate command signal for 
the elevons and elevator. It was determined that 
the maximum time required from pitch rate sensor 
input until this command was available as a surface 
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command was 5.9 msec. The onboard pitch rate 
surface commands were constrained to the 18.76- 
msec frame time (53.3 Hz) per elevon or elevator 
of the uplink, but alternating between the elevon 
and elevator frames so that a pitch rate command 
was sent to a pitch surface (elevons or elevator) 
at twice this rate or every 9.38 msec (see Uplink 
Encoder section). Although this time did not in- 
clude the servoactuator delay, it constituted a sig- 
nificant improvement over the time delay through 
the ground path. 

The onboard pitch gain was fixed at KBQ = 
-0.25 deg/deg/sec unless a transfer to DPM oc- 
curred and the elevators were locked. This gain was 
then multiplied by 2 owing to the availability of half 
of the pitch control surface and with an execution 
time of 18.76 msec. 

The RSS PCS control law is shown in figure 13. 
The ground-based longitudinal control law consisted 
of two distinct parts: the first was a pitch command 
augmentation system, referred to as the normal con- 
troller, and the second provided angle of attack and 
normal acceleration limiting. The feedback signals 
to the normal controller consisted of (1) low-pass fil- 
tered pitch rate at a fixed gain, (2) low-pass filtered 
normal acceleration at a fixed gain, and (3) high- 
pass filtered angle of attack used only at supersonic 
speeds to improve command response. These signals 
are summed with the shaped pilot’s stick command. 
The combined signal was then multiplied by a gain 
factor scheduled as a function of dynamic pressure. 
These signals were then output to logic that de- 
termined which commands would be honored, the 
normal controller’s or the limiters’. Assuming that 
the vehicle was not at either of its limits, the sig- 
nal was summed with a forward integration of the 
signal and a command was output to both elevators 
and elevons. The forward loop integrator provided 
longitudinal trim as long as the stick was centered. 
Fader elements were implemented in the command 
paths and provided the same function as the sta- 
ble PCS. The commands were then summed with 
auxiliary input signals generated in the V-73A com- 
puter and controlled manually on the CSMC panel 
at the cockpit. These auxiliary inputs consisted of 
flutter excitation pulses and commanded step and 
pulse inputs for data analysis. In addition, each of 


the feedback gains could be multiplied by constants 
if system considerations dictated. These constants 
were also programmed in the V-73A computer and 
were manually selectable on the CSMC panel. As 
in the stable PCS, a launch mode input was imple- 
mented which inserted a nose down bias command 
for the first 3 sec following launch, thus ensuring 
positive separation from the B-52 aircraft. Table 7 
presents all RSS PCS gains, gain schedules, and fil- 
ter representations. 

The angle-of-atta.ck limiter schedule is shown in 
figure 14. The positive limit was constant between 
low Mach numbers and 0.8 at 12° and 15° between 
Mach 0.9 and higher. Negative angle-of-attack limit 
was —3°. 

Lateral-Directional RSS PCS 

The lateral-directional RSS PCS control law is 
shown in figure 15. The roll rate feedback signal was 
summed with the low-pass filtered lateral stick input 
to form the roll command. The roll rate gain was 
a scheduled function of both dynamic pressure and 
Mach number while the lateral stick gearing gain 
was a function of Mach number only. The roll com- 
mand controlled only the asymmetric elevon. The 
rudder command consisted of the combination of 
(1) rudder pedal position, (2) lateral stick input, 
(3) lateral acceleration, and (4) yaw rate. The rud- 
der pedals in the HiMAT were seldom used. The 
aileron-to- rudder interconnect was a scheduled func- 
tion of angle of attack. The lateral acceleration gain 
was a scheduled function of dynamic pressure, and 
the yaw rate was low-pass filtered with the gain a 
scheduled function of both dynamic pressure and 
Mach number. Manually switchable gain functions 
were also implemented for roll and yaw rates and 
lateral acceleration for use as required. Faders and 
pulse panel inputs were used for the same functions 
described previously. 

Backup Flight Control System Modes 

The BCS was a full-authority, three-axis, multi- 
mode, multirate digital controller with stability aug- 
mentation functions and mode command functions. 
The seven BCS modes are listed in table 5. A brief 
discussion of these seven modes follows. 
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Climb-Dive Mode 


Recovery Mode 

The BCS was initialized in the recovery mode 
and generally every transfer to BCS sequence oc- 
curred through this mode. The recovery mode 
brought the vehicle to straight and level flight. If the 
altitude rate was greater than 12,000 ft /min when 
BCS was engaged, an inverted recovery would occur 
to preclude potential engine flameout and lubrica- 
tion problems. During the recovery sequence, dis- 
crete commands were not accepted into the BCS. 
The BCS would not exit the recovery mode until 
the Mach number was less than 0.96 and until the 
altitude rate was less than 600 ft /min. When these 
conditions were satisfied, external commands were 
accepted and a 25-sec timer was initiated. Once re- 
covery was complete, the mode would automatically 
change to heading hold and altitude hold until an- 
other command was received, or until expiration of 
the 25-sec timer, when the mode would go to orbit 
unless an exit orbit command was present. 

Orbit Mode 

The orbit mode and direction of turn were se- 
lectable via the discrete panel. Orbit mode could 
not be entered until the 25-sec timer had expired. 
When the orbit mode had been entered, the vehicle 
would automatically climb or dive to one of three 
preselected orbit altitudes at a fixed altitude rate of 
6000 ft /min and at a bank angle of approximately 
35°. Dive to orbit altitude would occur only at alti- 
tudes above 25,000 ft; at lower altitudes, the vehicle 
would climb to orbit. 

When orbit altitude was reached, the alti- 
tude rate was commanded to zero and the vehi- 
cle continued to orbit at constant altitude, air- 
speed, and bank angle until an exit orbit command 
was received. 

If telemetered (TM) carrier signal was lost at 
any time, a 25-sec timer was initiated and the vehi- 
cle entered the orbit mode upon expiration of this 
timer; it then remained in orbit until communica- 
tion was reestablished. If the engine failed during 
loss of communication, the vehicle would spiral to 
the ground. 

If exit orbit had been selected, the BCS was in 
altitude hold, airspeed hold, and heading hold until 
another command was received. 


All climbs or dives were done at fixed values 
of altitude rate and could not be adjusted by the 
pilot. Climbs or dives were at 6000 ft/min, with the 
exception of dives begun below 10,000 ft, which were 
at 3600 ft/min. The throttle responded to maintain 
the appropriate airspeed in climbs or dives. Turns 
could be executed while in a dive or climb. 

Turn Mode 

Two types of turns were available and were pi- 
lot selectable. The first was attitude command and 
the second was roll rate command. In attitude com- 
mand, vehicle attitudes were computed in the BCS 
by integrating a direction cosine set, using vehicle 
angular rates as inputs. In attitude command, turns 
were at bank angles of approximately 35°, or, if the 
pressure altitude was below 4000 ft, at bank an- 
gles of 20°. In roll rate command, the pilot could 
roll the vehicle to any bank angle at a rate of 15 
deg/sec. Therefore, when in roll rate command, the 
pilot had to monitor vehicle bank angle by video, 
the attitude-direction indicator, or visually in the 
case of the chase controller. The roll rate command 
system was included to provide the pilot with the 
capability to make small heading corrections during 
final approach. 

Landing Mode 

The landing mode was a pilot-selectable switch 
function. Vehicle airspeed and descent rate were 
scheduled functions within the BCS and were keyed 
on radar altitude. The radar altimeter range was 
from 0 to 5000 ft, so landing mode was usually 
selected at altitudes below 5000 ft above ground 
level (AGL). Once the vehicle had been maneu- 
vered to a position where the landing mode could 
be engaged, the pilot need not provide additional 
inputs for landing, although the system did have 
the capability of modulating both airspeed and al- 
titude rate during the landing approach. Mini- 
mum airspeed in the landing mode was 185 knots, 
and commanded altitude rate at zero altitude was 
—5 ft /sec. 

Engine-Out Mode 

In the engine-out mode, the BCS used the 
elevons for glide airspeed control and altitude-rate 
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control in the landing flare. Commanded glide air- 
speed was 215 knots, but the pilot could control air- 
speed from 165 to 300 knots via the BCS throttle- 
control discrete switch on the left console. The BCS 
transferred from speed command (glide) to altitude- 
rate command (flare) at 550 ft AGL. Airspeed at 
the 550-ft point was to be no higher than 240 knots 
nor lower than 190 knots, with pilot commanded 
gear deployment at approximately 70 ft AGL. In 
the flare, the commanded altitude rate was ramped 
from the existing altitude rate at 550 ft to -5 ft/sec 
at 25 ft. 

Backup Flight Control System Loop 
Structure 

Longitudinal RSS BCS Control Law 

Loop Structure 

The BCS longitudinal stabilization control loop 
is shown in figure 16. This loop consisted of direct 
pitch rate feedback plus an integral feedback combi- 
nation of washed-out pitch rate and load factor. The 
direct pitch rate gains were scheduled as a function 
of air data parameters. 

The outer-loop commands were input as a load 
factor command that was a function of the internal 
BCS logic state. The longitudinal portion of the 
recovery-mode command loop is shown in figure 17. 
Static pressure was the only input to the longitudi- 
nal path in this mode. The derived altitude rate was 
subtracted from the initial altitude rate to form the 
altitude-rate error, which was driven to zero, thus 
bringing the vehicle to level flight. 

Figure 18 shows the altitude-hold, climb-dive, 
and landing mode loop structure. As in the case 
of the recovery mode, static pressure was the only 
input. The climb-dive and landing modes were 
altitude-rate commands so the loop structure was 
similar in each case. In the climb-dive mode, the 
commanded altitude rates were fixed; in the land- 
ing mode, they were a scheduled function of radar 
altitude. The altitude-hold mode maintained con- 
stant altitude based on the difference between exist- 
ing static pressure and the altitude-hold pressure, as 
determined by the track and hold function. This dif- 
ference was then multiplied by the GRAD function 
to determine altitude error. 


Altitude rate was computed in BCS based on an 
analog differentiation of static pressure. Static pres- 
sure rate was then multiplied by the GRAD func- 
tion, which was the gradient of static pressure with 
altitude, to determine the derived altitude rate. Al- 
titude rate was not determined by a differentiation 
of radar altitude. 

Lateral-Directional RSS BCS Control 

Law Loop Structure 

Figure 19 presents a simplified concept of the 
lateral-directional BCS. Two turn modes were avail- 
able: a roll rate command mode provided the ability 
to command bank-angle changes of any desired mag- 
nitude at a constant 15 deg/sec roll rate, and the 
attitude command mode provided a wing-leveling 
function and a constant 35° or 20° bank-angle turn 
capability. To accomplish the attitude command 
task, a direction cosine algorithm, integrating vehi- 
cle angular rates, was mechanized in the BCS. The 
simplex vertical gyro was used to update the direc- 
tion cosines every 5 sec. In the event of a vertical 
gyro failure, a manual discrete, at the pilot’s station, 
discontinued the 5-sec update, and update was then 
referenced to a set of constants when wings were 
level, as determined by small angular rates. The 
direction cosines were used to calculate bank-angle 
error flags, which were used in the internal BCS logic 
to determine when and in which direction to com- 
mand roll. A heading-hold function became active 
when the BCS was not in a turn. The BCS direc- 
tional stabilization consisted of a yaw rate feedback 
for flights with a forward center of gravity. With 
0 percent or more aft center-of-gravity positions, a 
lateral acceleration feedback was included. 

BCS Throttle Control Law 

All airspeeds in the throttle control law (fig. 20) 
were determined based on an impact-pressure com- 
mand. Above 20,000 ft pressure altitude, Mach 
number was determined by a schedule of impact- 
to-static-pressure ratio for the commanded Mach 
number. This pressure ratio was then multiplied by 
the measured static pressure, and the impact pres- 
sure for that Mach number at that altitude was is- 
sued as the commanded input. Below an altitude 
of 20,000 ft all airspeeds were determined based 
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on scheduled impact-pressure command schedules. 
Impact-pressure rate was used for airspeed damp- 
ing. Above 20,000 ft, the BCS commanded a Mach 
number of 0.8; below 20,000 ft, it commanded a con- 
stant airspeed of 300 knots. The pilot had limited 
control over airspeed: to Mach 0.9 or 350 knots at 
the high end and to 185 knots at the low end. 

Additional information concerning BCS loop 
structure is contained in Hoyt and others (1980) and 
Woolley (1978). 

FLIGHT SYSTEMS FAILURE 
MANAGEMENT 

The dominant IliMAT systems design requirement 
that no single failure will result in the loss of the ve- 
hicle describes the overall failure management strat- 
egy used on the HiMAT program. Fault detection 
mechanisms existed in the hardware and software of 
the ground and airborne HiMAT systems. The hier- 
archy of HiMAT systems failure detection is shown 
in figure 21. The failures detected by the ground and 
airborne systems are outlined in tables 8 and 9, re- 
spectively. Most of the failure indications were dis- 
played to the systems engineer in the control room 
on the master caution and warning panel (MCWP) 
shown in figure 22. Most of the system faults il- 
luminated a master abort light which was used as 
an abort mission and return to base signal. A few 
of the more important failure indications were dis- 
played directly to the pilot on cockpit annunciators. 

The faults detected by the HiMAT onboard 
computer systems could be classified into four cate- 
gories, as follows: 

1. Caused automatic transfers to backup mode 

2. Prevented automatic transfers to backup 
mode 

3. Indicated mission abort conditions 

4. Indicated caution conditions 

The various system failures in the aforementioned 
categories are listed in table 9. 

The failure-detection mechanisms onboard the 
vehicles and on the ground were similar in 
philosophy. Watchdog timers, digital-to-analog 
converter (DAC) and analog-to-digital converter 
(ADC) wraparound tests and loop counters were 
used in computer self-tests; uplink and downlink 
discretes had to persist through multiple frames be- 


fore they were accepted. Uplink and downlink pro- 
portional data had to pass rate checks prior to ac- 
ceptance. Redundant analog inputs, such as air- 
borne sensors and ground stick, were compared with 
predetermined tolerances. 

Ground Failure Management 

Failure detection and management in the ground- 
based computer software (table 8) included a 
variety of different tests that determined the 
health and validity of the downlink signal and 
ground systems. 

Downlink Integrity 

The following tests determined the integrity of 
the downlink signal: 

1. Downlink discrete persistence check — The 
downlink discretes were required to remain con- 
stant for three consecutive frames prior to being 
honored as a true change in state, that is, true 
or false. 

2. Downlink parameter rate check — The rate 
of change of downlink parameters in excess of 
100 PCM counts from one frame to the next was 
not honored as legitimate data. 

3. Downlink word counter check — A counter in 
the last two words on the downlink was checked to 
ensure that the values were changing and that the 
V-77 computers had not failed. 

Uplink Integrity 

The following tests determined the integrity of 
the uplink signal: 

1. Uplink proportional rate check — The uplink 
aerodynamic surface commands were rate limited to 
ensure that these commands did not exceed the rate 
limits of the vehicle servoactuators. 

2. Uplink discrete check — The cockpit input 
discretes were required to persist for two frames 
prior to being honored as a true change in state. 

Real-Time Loop Integrity 

The V-73 computer performed a dual function 
of computing air data calculations for display in the 
cockpit and computing the PCS control law. Failure 
detection was mechanized for both these functions 
and included the following: 
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1. Nonsynchronous or instrument model loop 
check — This test checked a 10-frame counter. If the 
counter was not reset within 10 frames, the instru- 
ment model was declared failed. 

2. Primary real-time loop check— A time-out 
counter was checked to determine that the primary 
real-time loop (PCS control law) was operating. If 
this counter was not reset in 20 frames, the primary 
loop was declared failed. 

Computer Watch-Dog Timer 

The V-73 watch-dog timer consisted of missing 
pulse detector routine contained in the V-73 com- 
puter. This routine was called each frame, and if 
missing, a failure was declared. 

Stick Input Checks 

The dual stick, rudder, and throttle inputs were 
checked to ensure that they were within tolerances. 
If tolerances were exceeded, stick failure was de- 
clared. 

D AC/ ADC Wrap Tests 

A wraparound test from DAC signals to ADC 
signals was made to check real-time input-output 
(10). If this test failed, a stick fail annunciation was 
made in the cockpit. 

Air-Data Miscompares 

The dual air data parameters were compared to 
ensure meeting tolerances. If air data miscompare 
was declared, air data fail annunciation was made 
in the cockpit. 

Angle-of- Attack Miscompares 

The dual angle-of- at tack signals were compared 
to ensure that they were within 2° of each other. If 
a difference of 2° was exceeded, an angle-of-attack 
failure was declared and the RSS PCS angle-of- 
attack signal was ramped to zero and held until the 
failure was cleared. 

Airborne Failure Management 

Airborne failure was managed by airborne software 
when failures were detected in software or hardware. 
Failure consequences and failure annunciation to the 


ground station are summarized in table 9. Nor- 
mally, failure indications were downlinked for dis- 
play in the cockpit and the MCWP. Fault detection 
was a primary computer task, with uplink system 
failure and computer self-test diagnostics done in 
both the primary and backup computer. 

Hydraulic Systems 

Failure of hydraulic systems was detected by 
monitoring hydraulic pressure and hydraulic fluid 
level in both primary and backup hydraulic sys- 
tems. A primary hydraulic system failure resulted 
in an automatic transfer to BCS while a backup 
hydraulic failure inhibited automatic transfers 
to BCS. 

Electrical Systems 

Electrical systems failure was detected by mon- 
itoring primary electrical (generator) and backup 
electrical (battery) voltage. A primary electrical 
failure resulted in an automatic transfer to BCS. 
Hardware was mechanized to monitor the generator 
bus and did an automatic bus split if the voltage fell 
to approximately 26 V. 

Duplex Actuators 

A failure in the primary side of a duplex actua- 
tor resulted in an automatic transfer to BCS, while 
a failure in the secondary side inhibited a transfer 
to BCS. Two methods for determining failures of a 
duplex actuator were used. First, a failure in the 
duplex rudder was detected by a cross- ship com- 
parison as in the simplex actuators. Second, fail- 
ure detection in a duplex elevon servoactuator was 
mechanized, external to the onboard computers, in 
the servoactuator electronics (SAE) box. An analog 
model that duplicated the elevon servovalve dynam- 
ics was used to detect failures. The actual servovalve 
signals were combined with the modeled values to 
form an error signal which was then sent to the pri- 
mary computer for processing. 

Simplex Actuators 

Failure of the simplex actuators (elevator, ca- 
nard, and aileron) was detected by a cross-ship com- 
parison algorithm in the primary computer. In the 
event of a cross-ship miscompare of a simplex ac- 
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tuator, the primary computer commanded an au- 
tomatic transfer to BCS. Upon transfer to BCS, 
all simplex actuators were commanded to their 
locked positions. 

Triplex Sensors 

Triplex sensor failure was detected by com- 
paring the output of the two nonmidvalues with 
the midvalue output for each of the five triplex 
sensor sets. Failure indications (miscomparisons) 
were downlinked to the ground and annunciated 
on the MCWP; however, no automatic action was 
taken, since a failed sensor would have been voted 
out of the system by the midvalue selection pro- 
cess. If the number three sensor of a triplex 
set failed (number three sensor outputs were in- 
put to the BCS), automatic transfers to the BCS 
were inhibited. 

Duplex Sensors 

Air data duplex sensor faults were detected by 
comparing the primary static and impact pressure 
transducer outputs with those of the correspond- 
ing backup transducer outputs. If a disagreement 
existed, the state was downlinked for resolution on 
the ground. The static and impact pressures were 
also used to digitally compute predicted static and 
impact pressure rates. These predicted rates were 
then compared with the analog differentiated rates 
to determine if the air data pressure rate failed. 

Downlink System 

A failure in the downlink system was deter- 
mined by the loss of synchronization between the 
onboard computer and the flight test instrumenta- 
tion system. A loss in synchronization would auto- 
matically result in a transfer to the BCS. 

Uplink System 

The uplink monitoring logic determined 
whether both decoders were operational, which was 
a requirement to remain in the PCS mode, and 
whether the uplink command discretes were valid. 

The PCS required a complete set of propor- 
tional commands to be available for output to the 
control surfaces. If missing data indicated one or 


both decoders failed, an automatic transfer to BCS 
was commanded. 

As shown in figure 6, the critical uplink com- 
mand discretes were sent to both decoders. Discrete 
validity was ensured by two methods: a persistence 
test guarded against noise being interpreted as a 
command; and if both decoders were operational, 
the discretes from the two decoders had to agree 
before they were acted upon. If a discrete differ- 
ence between decoders occurred, it was possible for 
the ground station to command the onboard system 
to use the discretes from the decoder whose data 
were correct, based on information telemetered to 
the ground. 

Computer Self- Test Diagnostics 

The computer intercom was checked by sending 
a diagnostic test message from the primary com- 
puter to the backup computer. The backup com- 
puter echoed the message to the primary computer 
where it was checked for accuracy. Two different 
messages were used so that all bits could be checked 
in both the on and off states. 

Self-test software was used in each com- 
puter. These tests included random access mem- 
ory (RAM), erasable programmable read only mem- 
ory (EPROM), hardware multiplier tests, ADC and 
DAC tests, and instruction diagnostic tests. If a 
failure was detected, the failed computer would take 
itself off-line by turning on its computer failure dis- 
crete output and freezing its watchdog pulse out- 
put. A primary computer failure caused a transfer 
to BCS, while a backup computer failure inhibited 
automatic transfers to BCS. 

Systems Flight Qualification 

Qualification Tests 

Extensive qualification testing of all aircraft 
systems and subsystems hardware, and ground and 
airborne software was required to certify a HiMAT 
vehicle for flight. Onboard computer hardware was 
qualified environmentally by the use of components 
meeting military specifications and by environmen- 
tal tests both before and after delivery. Computer 
hardware was tested to the requirements of standard 
specifications. 
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The onboard computer interfaces were verified 
in four different test sequences (integrated systems, 
combined systems, iron bird, and preflight), por- 
tions of which were repeated anytime a modification 
was required to the interface. 

The integrated systems test sequence demon- 
strated that each vehicle subsystem operated cor- 
rectly. This test phase included signal interface 
and continuity checks, power system checks, the 
functional qualification of both the backup and 
primary hydraulic and servoactuator systems, vehi- 
cle telemetry uplink and downlink systems testing, 
and engine test runs with the engine both installed 
and uninstalled. 

Combined system testing was conducted with 
the HiMAT vehicle operating in combination with 
the RPRV facility. All ground and airborne systems 
were active in these tests with the exception of the 
radiofrequency links, which were hard-lined with ca- 
bles. This test sequence included end-to-end signal 
verification, closed-loop total system and subsystem 
time delay measurements, ground resonance tests, 
and automated preflight testing, both onboard and 
ground based. Open-loop failure modes and effects 
tests were conducted to validate proper system re- 
sponse to component and subsystem failures. 

The iron bird simulation test sequence ex- 
panded the combined systems test configuration to 
include real-time simulation of the vehicle dynam- 
ics, aerodynamics, and engine model. Tests con- 
ducted during this phase included dynamic response 
for both the PCS and BCS flight modes, limit cycle, 
closed-loop failure modes and effects, piloted eval- 
uation and training, and a complete mission pro- 
file simulation. 

Vehicle preflights were a final check of all vehi- 
cle subsystems and were performed as close to each 
flight as possible. This test sequence used the inter- 
face capability resident in the onboard computers 
to verify interface and subsystem operation. Upon 
completion of the preflight check, all subsystem con- 
figurations were frozen and could not be changed 
without invalidating the preflight checks. If removal 
of hardware was required, a preflight check was per- 
formed again on that item. 


Simulation Systems 

Four types of simulations were used to qual- 
ify onboard computer software (Evans and Schilling, 
1983; Evans and Schilling, 1984). In each of these 
systems, the vehicle dynamics were simulated in 
the Dryden Cyber 73-28 computer (Cyber Systems, 
Inc., Anaheim, California). The four HiMAT sim- 
ulation systems, termed ALL-Cyber, Cyber- Varian, 
CASH, and iron bird are described in the following 
paragraphs. In the order presented, each included 
more actual HiMAT hardware in the loop than the 
previous one. 

The ALL-Cyber simulation (fig. 23) was the 
principal tool in the design and development of both 
the BCS and PCS software since it permitted de- 
signs to be verified in a dynamic environment before 
they were implemented in the ground and airborne 
flight computers. In this simulation, the HiMAT 
servoactuator system and the uplink and downlink 
systems were all modeled, along with HiMAT vehi- 
cle dynamics, using a Cyber 73-28 computer. This 
simulation was interfaced by way of the Cyber com- 
puter’s real-time input-output system with a Hi- 
MAT simulation cockpit. 

The Cyber- Varian simulation (fig. 24) allowed 
much of the HiMAT PCS software to be validated in 
the simulation facility with ground computers iden- 
tical to those used for flight, and with a full simula- 
tion of the HiMAT vehicle dynamics. Simulation 
cockpit uplink and downlink interfaces permitted 
ground-based software to be identical to the soft- 
ware for the RPRV facility computers. This sim- 
ulation method was the least useful for design or 
verification of onboard software. 

The computation and simulation of HiMAT 
(CASH) system (fig. 25) went a step further than 
the Cyber- Varian simulation just described. In this 
simulation, the actual HiMAT onboard computer 
was interfaced with the Cyber and simulation fa- 
cility ground computers. An uplink encoder was 
hard lined to an uplink decoder, bypassing only the 
transmitter-receiver radiofrequency link. The de- 
coder was interfaced with the onboard computer 
just as in the flight configuration. A high-fidelity 
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and effects testing and systems hardware and soft- 
ware validation. 

Configuration Control 

Rigorous configuration control procedures were 
used to track both ground and onboard flight hard- 
ware and software changes. An outline of the config- 
uration control process is shown in figure 27. Hard- 
ware and software changes resulted from changes in 
requirements or from system discrepancies. Proce- 
dures were provided for documenting and tracking 
all discrepancies and changes. All changes, includ- 
ing those associated with discrepancies, were ap- 
proved by a configuration control board before they 
could be implemented for flight. Hardware changes 
were tracked by the NASA work order and the Hi- 
MAT discrepancy report systems. Software changes 
were tracked by the program change-program ver- 
ification and validation paperwork and procedures. 
Each change was verified and validated and software 
documentation updated before the change was ap- 
proved for flight. 

Changes to onboard software required the man- 
ufacture of a new flight release. Source code changes 
were incorporated in a source file maintained on 
the Cyber computer; then the new total program 
was assembled by the cross assembler on the Cy- 
ber computer. The Intel hexadecimal format ob- 
ject code was transported and loaded into the MDS 
to program the EPROMs used in the flight com- 
puter. An octal memory check sum was computed 
from the assembled output on the Cyber computer 
and compared with that computed in the HiMAT 
onboard computer as part of its self-test; this pro- 
cess partially verified that the cross-assembler out- 
put had been accurately transferred to the flight 
computer. Software verification and validation test 
procedures used the flight release. These tests were 
performed in a laboratory environment using the in- 
circuit emulator and the computer test set, in the 
simulation laboratory using the CASH simulation, 
or on the aircraft using the iron bird simulation or a 
stand-alone configuration. Primary and backup on- 
board computer flight releases were manufactured 
independently, although in practice, both comput- 
ers were updated in the same time period. Further 
information on the qualification procedures used for 
HiMAT can be found in Myers and Sheets (1980). 


PRIMARY CONTROL 
SYSTEM FLIGHT TEST 
RESULTS 

Verification of Vehicle Aerodynamics 

During the 26-flight test program on the two Hi- 
MAT vehicles, 12 flights were devoted to the ac- 
quisition of aerodynamic data to verify wind tun- 
nel data. This series of flights was flown with the 
vehicles ballasted in a stable or forward center-of- 
gravity configuration ensuring stable open-loop ve- 
hicle dynamics. This configuration was flown, using 
the stable PCS, so that the flight control system 
gains could be greatly reduced or set to zero during 
stability and control maneuvers, resulting in min- 
imum control surface motion during the transient 
portion of these maneuvers. With the stable PCS 
mechanized in FORTRAN, it was relatively simple 
to write code to generate specific inputs to the con- 
trol surfaces. These inputs included independent 
control surface steps and pulses of various ampli- 
tudes and decoupling elevon inputs from the eleva- 
tors or ailerons. The acquired flight data were then 
used as inputs to a maximum likelihood estimator 
for estimating the flight aerodynamic stability and 
control derivatives (Matheny and Panageas, 1981). 
Using the flight-determined aerodynamic data, the 
RSS PCS was then configured for the RSS portion 
of the flight test program. 

In addition to determining stability and con- 
trol data, various control system configurations were 
evaluated. These evaluations included the rolling 
capability of the airplane with differential elevon 
only and aileron- to-rudder interconnect. 

Control Surface Pulse Command Inputs 

Pulse magnitude, direction, and duration were 
controlled from the pulse panel by a flight test en- 
gineer. Figures 8 and 9 show pulse inputs to the 
flight control system. The pulse inputs were inde- 
pendent of each other, as in the case of the elevon 
and elevator, which normally operated in unison, so 
the effects of each could be determined independent 
of the other. In this configuration, system feedback 
gains were usually set to zero for the pulse sequence. 
Typical pitch elevon and elevator pulse inputs and 
vehicle transient response are shown in figure 28. 
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electronic model of each of the HiMAT servoactua- 
tor channels was interfaced with the onboard com- 
puter, and the output of these actuator models was 
monitored by the Cyber computer that calculated 
vehicle response. This configuration was used exten- 
sively for both ground and airborne software valida- 
tion and verification since both the BCS and PCS 
software were executed in computers identical to 
those used for flight. 

The iron bird simulation (fig. 26) represented 
the most sophisticated of the HiMAT ground test 
phases, making maximum use of actual flight hard- 
ware by incorporating the flight vehicle in the loop. 
In this configuration, the aircraft and RPRV facil- 
ity systems were made to function as if the HiMAT 
vehicles were in flight. With the HiMAT vehicle in 
the hangar, the telemetry downlink was hard lined 
to the RPRV facility, as was the uplink command 
system to the vehicle; all vehicle control loops were 
active. The simulation of the vehicle dynamics was 
similar to that used in the CASH system except 
that actual surface positions were interfaced with 
the Cyber 73-28 computer. Vehicle response data 
were trunked to the vehicle, summed with the actual 
vehicle transducer outputs, and input to the teleme- 
try downlink system. The iron bird simulation pro- 
vided for a full system validation of both the BCS 
and PCS. Additional information on HiMAT simu- 
lations can be found in Evans and Schilling (1983) 
and Myers (1979). 

Initial attempts to accomplish satisfactorily an 
iron bird simulation with the vehicle in the RSS con- 
figuration were unsuccessful owing to the slow frame 
rate of the Cyber computer of only 18.75 msec per 
frame. Several approaches were attempted to elimi- 
nate the limit cycles caused by the total system de- 
lays (see Myers, 1979, for additional details). The 
slow frame rate was solved by including an array 
processor that executed the aerodynamic model and 
computed the vehicle airframe dynamics. The array 
processor, in conjunction with one of two new main 
simulation computers, was synchronized to the on- 
board computers at 4.54 msec per frame (220 Hz) 
and provided sufficient update rates critical to the 
onboard pitch rate feedback loop. The array pro- 
cessor enabled the RSS PCS and BCS to be flight 
qualified in the iron bird configuration. 


Software Qualification 

Flight software underwent two types of test- 
ing during the process of flight qualification: ver- 
ification and validation testing. Verification testing 
checked software performance by devising individual 
tests for each specified software task, conducting the 
test, and observing that the task met the specifica- 
tion. Validation testing was the broader task that 
sought to determine if the system, of which the soft- 
ware was a part, met flight requirements. Failure 
modes and effects tests (both open loop and closed 
loop) were among the techniques used in software 
validation. In these tests, failures were artificially 
induced, and a proper system response to those fail- 
ures was verified. 

The onboard flight software was developed and 
verified using a microprocessor development system 
(MDS) and the airborne computer test set, which 
was a stand-alone bench facility that simulated 
the HiMAT systems-computer interfaces. Software 
was validated primarily with CASH and iron bird 
simulations. 

Ground Test Requirements 

Adequate ground test and computer interface 
equipment was essential to qualify the airborne sys- 
tem in the operational configuration. As delivered, 
computer memory display consisted of a three-digit 
octal display addressable by thumbwheel switches. 
Only 1 byte of RAM at a time could be interro- 
gated while many parameters were stored as 16-bit 
(2-byte) quantities. This minimal capability was in- 
adequate to verify hardware interfaces, or software. 

As a result, the aircraft interrogation and dis- 
play system (AIDS) was developed to provide in- 
creased onboard computer system visibility. The 
AIDS was an independent microprocessor-based 
system that interfaced with the HiMAT onboard 
computer. Any data available in the onboard 
computer memory could be displayed on a dy- 
namically refreshed cathode ray tube (CRT) mon- 
itor. Up to 20 individually labeled parameters 
could be displayed at a time in either raw input 
form or engineering units. This system also con- 
tained a printer that could be used to provide hard 
copy of any CRT display. The AIDS greatly re- 
duced the hours required to conduct failure modes 
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These pulses were at 1-g trim condition. Elevator 
and elevon amplitudes were 3° The vehicle pitch an- 
gular rate, angle of attack, and elevator and elevon 
surface positions are illustrated (fig. 28). 

A lateral- directional pulse set is shown in fig- 
ure 29. Differential elevon and aileron pulses were 
independent of each other, as shown in the figure. 
Illustrated are vehicle bank angle, roll rate, sideslip 
angle, yaw rate, differential elevon, aileron, and rud- 
der position (fig. 29). 

Aileron Active and Inactive 

The outboard ailerons produced large adverse 
yawing moment characteristics that were undesir- 
able from both a control system and a handling 
qualities viewpoint. Within the scope of the HiMAT 
program, there was no specific requirement for the 
roll control power provided by the ailerons. It was 
felt that only differential elevon could provide the 
required roll control power while significantly reduc- 
ing adverse yaw and simplifying the flight control 
system. Therefore, it was proposed that a piloted 
evaluation be made with the ailerons locked and un- 
locked on the same flight. With the PCS mecha- 
nized in software, it was relatively simple to include 
FORTRAN code that eliminated the ailerons from 
the PCS with a discrete command switch on the 
pulse panel. Figure 30 presents the time response 
of a piloted evaluation of aileron control using both 
aileron and differential elevon. Adverse yaw can 
be seen with the sharp left (right) roll command 
input and the corresponding right (left) induced 
sideslip. Figure 31 is a similar time response (on 
the same flight) with the ailerons locked. In this 
time response, the magnitude of the adverse yaw 
was greatly reduced. From these evaluations and 
assessment of other aerodynamic data, it was de- 
cided to lock mechanically the ailerons on all flights 
after the eighth flight of vehicle number one. 

Aileron-to-Rudder Interconnect 

To further reduce adverse yaw owing to dif- 
ferential elevon, an aileron-to-rudder interconnect 
(ARI) was mechanized in software and was evalu- 
ated in flight. Figure 32 shows the time response 
of a 5° differential elevon step input with aileron- 
to-rudder interconnect gains (KARI) of zero and 
-0.133 deg/deg, respectively. Note that as the KARI 


gain was increased, the induced sideslip was reduced 
and the steady state roll rate response was improved 
from approximately 16 deg/sec to 32 deg/sec. With 
KARI at -0.133 deg/deg, the induced sideslip was 
zero and the roll rate response was first order. As 
a result of this study, an ARI gain schedule was de- 
veloped for the RSS flight control system. 

Relaxed Static Stability Configuration 

Using the data acquired from the stable portion of 
the flight test program, the RSS PCS was configured 
and the second phase of the flight test program was 
conducted. The following discussions present situa- 
tions encountered in the RSS portion test program 
and the results of concerns such as control surface 
rate adequacy. 

Lateral Acceleration Aliasing 

The phenomenon of aliasing is fundamental in 
the sampling of data at equally spaced time inter- 
vals such as in the 220-IIz PCM downlink system 
aboard the HiMAT vehicles. In actuality, a high 
frequency can be aliased into a low frequency as a 
result of sampling the data. During the first aft 
center-of-gravity flights (the 10th flight of vehicle 
number one), a low-frequency (0.67 IIz) oscillation 
appeared on the lateral acceleration input to the 
PCS. This low-frequency oscillation (fig. 33) was in- 
terpreted by the PCS as a rigid body aircraft mode 
and commanded rudder inputs to damp the motion. 
However, vehicle motion was induced rather than 
damped. This indication of a pseudolow-frequency 
lateral oscillation was attributed to a high-frequency 
engine vibration being aliased via the lateral ac- 
celerometer through the PCM system to the ground- 
based PCS. 

The lateral accelerometer was provided with a 
first-order antialiasing filter with a break frequency 
of 25 Hz and was sampled at 220 Hz or samples 
per second. It was determined that the HiMAT 
engine idle speed was approximately 220 rev/sec. 
Figure 33 presents a 16-sec time interval of lateral- 
directional flight data shortly after launch. Initially, 
the throttle was at idle as indicated by the 14° of 
throttle position. The 0.67-Hz oscillation can be 
seen on yaw rate, lateral acceleration, and rudder 
position. As the throttle was advanced from 14° to 
about 34°, the frequency of the lateral acceleration 
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changed from 0.67 Hz to approximately 3.3 Hz. The 
rudder response was seen to increase in frequency, 
however, the amplitude was significantly reduced as 
was the resulting vehicle motion. As throttle was 
increased toward 50°, the lateral acceleration fre- 
quency increased to approximately 10-Hz. Again, 
the rudder response also increased in frequency, but 
the amplitude was again reduced. Throughout the 
entire time interval, the lateral acceleration ampli- 
tude remained about the same, which suggested a 
very large mechanical vibration at the accelerometer 
package location. This problem was solved by mech- 
anizing of a second-order antialiasing filter with 25- 
Hz break frequency and 0.5 damping ratio in the 
lateral acceleration channel and no further problems 
were encountered. 

Angle-of- Attack Limiter 

To protect against a predicted severe increase 
in the longitudinal instability, or pitcliup, as a 
function of angle of attack and Mach number, an 
angle-of-attack limiter was mechanized in the RSS 
PCS (see fig. 14). This angle-of-attack instabil- 
ity was believed to increase significantly between 
13° and 17° angle of attack at Mach 0.85 and to 
be significantly improved at Mach 0.90. At lower 
Mach numbers, this increase in longitudinal insta- 
bility was predicted to exist at lower angles of at- 
tack, resulting in the the PCS angle-of-attack lim- 
iter shown in figure 14. Figure 34 presents a flight 
test experience of this increase in longitudinal in- 
stability (illustrated as a pitchup) and the effec- 
tiveness of the angle-of-attack limiter to recover 
the airplane. 

The maneuver shown in figure 34 was a tran- 
sonic windup turn. The pitchup occurred at the 4.4- 
sec point with the vehicle at 11.8° angle of attack, 
Mach 0.87, 7.2-g normal acceleration, 15 deg/sec 
pitch rate, 83° bank angle. The maneuver was pro- 
gressing smoothly until the pitchup at the 4.4-sec 
point. At this point the elevator began to move in 
a positive or nose down command direction. The 
vehicle, however, continued to pitch up even though 
there was a significant increase in the nose down el- 
evator command. At the 4.9-sec point, the airplane 
entered the angle-of-attack limiter and even more 
nose down elevator was commanded. Between 5.1 
and 5.2 sec, the maximum angle of attack of 14.5° 


and normal acceleration of 8.7 g were reached with 
a maximum nose down elevator command of +4.2°. 
At this point the vehicle pitched down and recov- 
ered as illustrated by the pitch rate (fig. 34). This 
maneuver was a good example of the effectiveness 
of the angle-of-attack limiting logic. 

Surface Angular Rate Probability 

Distribution 

During the course of the HiMAT program, a 
question was raised concerning aerodynamic control 
surface angular rates achieved in the RSS configu- 
ration as compared with the stable configuration. 
To answer this question, the landing approach flight 
condition was selected from comparable flights be- 
cause the vehicle was predicted to be the most aero- 
dynamically unstable as compared to other flight 
regimes. Table 10 presents the center-of-gravity lo- 
cation for the two 20-sec time intervals selected. 
Center of gravity was presented in percentage of 
mean aerodynamic chord (MAC) with respect to the 
reference center-of-gravity position. Aerodynamic 
static margin was also presented. In this flight con- 
dition, the vehicle was never actually statically un- 
stable, as indicated in table 10. Figure 35 presents 
the time response from two flights with the land- 
ing gear transient selected for analysis. The effect 
of center-of-gravity location can clearly be seen in 
the elevator position trace as indicated by the more 
positive (trailing edge down) position with the aft 
center of gravity. 

For this study, three individual surface 
positions were selected for analysis as being 
representative — left elevator, left elevon, and left 
rudder. Figure 36 presents the surface position 
time response for each of the flights; and figure 37 
presents the surface angular rates for the same time 
interval. Qualitative examination of the data indi- 
cated a significant increase in angular rates achieved 
for all surfaces for the aft center-of-gravity config- 
uration as compared with the forward center-of- 
gravity configuration. Figure 38 presents the prob- 
ability distribution for each of the configurations. 
The data for these curves were obtained for each 
of the three surfaces over a 20-sec time interval at a 
sample rate of 220 Hz for a total of 4400 data points. 
The curves are plotted as percentages of occurrence 
against angular rate. Perhaps the most significant 
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result was the rudder rate activity in the aft center- 
of-gravity configuration. Note in figure 38(a) that 
for the forward center-of-gravity case the vast ma- 
jority of time, the rudder was at zero or at very 
low rates, and for the aft center-of-gravity case even 
through the rates were relatively low, activity was 
significant. This general trend was evident for both 
elevon and elevator as shown in figures 38(b) and 
38(c), however, the trend was not as dramatic as the 
rudder. The highest angular rates during the time 
intervals of interest are presented in table 11. These 
results were consistent and were in the direction ex- 
pected, that is, increased angular surface rates for 
the aft center-of-gravity configuration. None of the 
angular rates approached the maximum rate capa- 
bility as indicated in table 1. 

Flight Test Maneuver Autopilot 

To meet the needs of the HiMAT program, a 
flight test maneuver autopilot (FTMAP) was devel- 
oped. This FTMAP was designed to provide precise 
vehicle control during required test maneuvers, such 
as pushover-pullups, windup turns, and “rocking- 
horse” maneuvers (Duke and others, 1986). Fig- 
ure 39 presents three examples of FTMAP gener- 
ated high-g windup turns. Mach number and al- 
titude were to be held constant while angle of at- 
tack was increased until normal acceleration of 8 
g was achieved. Mach number was to be held to 
0.90 ±0.01. As the maneuvers progressed, Mach 
number was held constant until the later portion of 
the maneuver, when engine thrust limit was reached 
and Mach number decreased and the maneuvers 
terminated. These maneuvers were of high qual- 
ity, repeatable, and typical of the results obtained 
from the FTMAP. Figure 40 presents two pilot- 
flown windup turns from similar initial conditions of 
figure 39. Pilot difficulty in flying these maneuvers 
is apparent from the time histories. Each of the ma- 
neuvers, by comparison with FTMAP results, was 
irregular and erratic with little repeatability. The 
FTMAP was capable of obtaining high-quality data 
in relatively short intervals and greatly unburdened 
the pilots. 


BACKUP CONTROL SYSTEM 
FLIGHT TEST RESULTS 

During the 26-flight test program on two HiMAT 
vehicles, there were a total of 24 transfers to DCS. 
There were a total of 16 transfers to BCS on vehicle 
number one with 12 of these transfers occurring on 
the first three flights. Only one transfer was owing 
to a hard system (number 1 decoder) failure that 
precluded a transfer back to PCS and resulted in the 
only BCS landing. There were 8 transfers to BCS 
on vehicle number two with one manual transfer. 
Vehicle number two did not land with BCS. 

All BCS modes except engine-out mode were 
exercised during BCS operation and all operated 
satisfactorily; no anomalies were observed. 

Stable Configuration 

Transfer to BCS Recovery Mode 

Each transfer to BCS resulted in a normal se- 
quence through the recovery mode. Figure 41 illus- 
trates three subsonic transfers from PCS to BCS. 
Figures 41(a) and 41(b) show a transfer from 90° 
right and left climbing turns at two airspeeds; the 
airspeed for the data in figure 41(a) was approxi- 
mately 260 knots and in figure 41(b) was 360 knots. 
Transfer to BCS occurred when the elevator went to 
its locked position, as shown in the figures. During 
the recovery sequence, the bank angle was brought 
to zero and zero altitude rate was achieved within 
about 8 sec of transfer. In figure 41(b), a PCS 
elevator-pitch pulse (for data purposes) was just 
completed when transfer occurred. Figure 41(c) 
illustrates a wings-level transfer. These recoveries 
were relatively typical of most transfers to BCS and 
occurred as predicted in closed-loop analysis. 

Orbit Mode 

The orbit mode was entered only once, when 
the pilot inadvertently left the cockpit orbit switch 
in the orbit position following a transfer to BCS. 
Figure 42 shows an entry into left orbit following 
expiration of the 25-sec recovery timer. When or- 
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bit mode was entered, the vehicle was in a 47° right 
bank and entry into this mode was inadvertent; con- 
sequently, the left orbit was not fully developed. 
Approximately 2 sec following entry into orbit, exit 
orbit was selected and the pilot reestablished his 
right turn. The orbit mode 20 deg/sec roll rate com- 
mand can be seen in the roll rate trace, as can the 
15 deg/sec roll rate command initiated by the pilot’s 
discrete turn switch. From the altitude rate trace, 
it can be seen that the BCS initiated a climb- to- 
orbit discrete. 

Dive Mode 

Figure 43 shows two relatively typical BCS 
dives initiated from the altitude-hold mode. Both 
examples are initiated from a wings-level condi- 
tion. Figure 43(a) represents a dive from above 
10,000 ft and figure 43(b) represents a dive from be- 
low 10,000 ft where the commanded dive rates are 
6000 ft /min and 3600 ft/min, respectively. In both 
figures, the desired dive rate was achieved; however, 
as shown in figure 43(b), the desired dive was not 
achieved until about 16 sec after dive initiation, as 
a result of lateral maneuvering. The lateral maneu- 
vering shown in these figures was in the roll rate 
commanded mode. 

Turn Mode 

Figure 44 presents examples of the two types of 
turn modes: attitude command and roll rate com- 
mand. In the attitude-command turn shown in fig- 
ure 44(a), the pilot initiates and maintains the turn 
command as the vehicle rolls (at the commanded 
20 deg/sec roll rate) to a bank angle of approxi- 
mately 30°. When approaching the desired bank 
angle, as determined by the direction cosine set, the 
roll rate command was released in the BCS logic. At 
this point, a bank angle of 37° was established and 
maintained by the BCS as the pilot continued to 
command a turn. In this mode, the bank angle and 
turn rate were maintained until the pilot released 
his turn command. 

Figures 44(b) and 44(c) present examples of 
turns in the roll rate command mode. In this mode, 
the pilot commanded a 15 deg/sec roll rate when 
he commanded turn and no limit was imposed on 
bank angle. These two examples of roll rate com- 
mand mode were relatively typical of the pilot’s 


use of this mode at lower altitudes in preparation 
for landing. 

Transfer From BCS to PCS 

Figure 45 shows the transfer from BCS 
to PCS. These transfers were relatively typical 
with an acceptable level of resulting transients. 
Note the level of vehicle activity as the pilot 
assumed control. 

Powered-Landing Mode 

On one flight an automatic transfer to backup 
occurred when an uplink receiver-decoder failed and 
a return to PCS was not recommended, thus com- 
mitting the airplane to a BCS landing. Before 
touchdown, it was determined that the landing gear 
could not be lowered; therefore, the vehicle was com- 
mitted to a gear-up landing. The subsequent gear- 
up landing was smooth and resulted in only minor 
damage to the lower external skin, antennas, and 
air scoops. The engine was not damaged. 

Figure 46 presents a comparison between flight- 
measured airspeed and descent rate with the BCS- 
scheduled commands for a powered landing. The 
dashed lines indicate the commanded values and the 
solid lines indicate flight-measured values, all as a 
function of radar altitude. Generally, good agree- 
ment exists between the BCS-commanded inputs 
and the flight data. Landing mode was selected at 
2900 ft AGL, and both airspeed and descent rate 
approached the scheduled commands. The devia- 
tions between 2900 ft and 1000 ft may have been 
caused by lateral maneuvering as the pilot flew the 
final approach in roll rate command. Touchdown 
airspeed appears to have been fast. 

Pilot Comments 

General pilot comments indicated that the BCS 
performed well throughout the flight-test program. 
In the landing mode with BCS, the approach to 
landing was very good, and the landing schedule 
provided a smooth touchdown. 

Relaxed Static Stability Configuration 

Aeroservoelastic Instability 

During flight testing, the IliMAT vehicle was 
monitored for possible aeroservoelastic (ASE) in- 
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stability. Such instabilities occur when the flight 
control system dynamically interacts with structural 
modes. Adverse structural coupling of the BCS was 
observed with the first wing-bending mode (9 Hz) 
on two occasions (Kehoe, 1984). 

Following a transfer to BCS at approximately 
Mach 0.9 at 37,000 ft altitude, a high-frequency low- 
amplitude pitch oscillation developed and sustained 
itself. Upon transfer back to PCS, this oscillation 
damped out. Transfer to BCS at 25,000 ft altitude, 
at approximately the same Mach number, did not 
excite this 9-tIz mode. Figure 47 presents a time 
history of this oscillation. After transfer to BCS, 
the amplitudes of this oscillation became limited 
and remained at relatively low amplitudes as can 
be seen in all the traces (fig. 47). Maximum ampli- 
tudes of normal acceleration were 0.2 g peak-to-peak 
and maximum pitch rates of 1.5 deg/sec peak-to- 
peak. The normal acceleration and pitch rates were 
approximately 180° out of phase with the wingtip 
accelerations. With the transfer to BCS, the sys- 
tem loop gain was such that the 9-IIz wing-bending 
mode was sustained through the pitch rate gyro. 

The BCS pitch rate gain was computed in the 
BCS control law and was a function of impact pres- 
sure with lower gains for higher pressures and higher 
gains for lower pressures. If the Mach number was 
0.9 and remained fixed for altitudes of 25,000 ft and 

37,000 ft, the impact pressure would be in the ratio 
of 1.74:1. In the BCS control law with Mach 0.9 
and the lower altitude of 25,000 ft and higher im- 
pact pressure, the resulting BCS pitch gain was sig- 
nificantly lower than for the same Mach number at 

37.000 ft. For this Mach number at 37,000 ft al- 
titude, the BCS pitch rate gain was approximately 
twice its value at 25,000 ft. At the lower altitude of 

25.000 ft when a transfer to BCS occurred, at a sim- 
ilar Mach number but higher airspeed (higher im- 
pact pressure) and lower pitch gain, this ASE prob- 
lem was not observed. Therefore, with a lower BCS 
pitch gain, the ASE instability was not a problem. 
A pitch rate notch filter was designed for this 9-Hz 
mode but never implemented, because this problem 
was observed late in the flight program and little 
flight test data was collected at altitudes higher than 

25,000 ft. 


Transfer to BCS Recovery Mode at 

Supersonic Speed 

One supersonic transfer to BCS occurred when 
the IliMAT vehicle was at Mach 1.29. Figure 48 
presents the flight-recorded longitudinal parame- 
ters of this transfer. As the vehicle decelerated, a 
relatively large static pressure rise, as a result of 
the passing shock wave, was sensed at the static 
pressure orifice. The BCS recovery mode inter- 
preted this large pressure rise as a rapid descent and 
sent a relatively large nose up command to counter 
the pseudoloss in altitude. Transfer occurred at 
about 1.4 sec at 1-g normal acceleration. The rapid 
pitchup resulted as the elevators moved to their 2.5° 
locked position and the elevons assumed full control. 
At the 10-sec point, the shock wave passed over the 
static pressure orifice and the BCS commanded nose 
up for about 2 sec, following which the recovery ma- 
neuver was completed. Also shown in figure 48 is 
a similar time response recorded from the IliMAT 
real-time CASH simulation. The initial conditions 
were the same as the flight data. Initial observation 
of the simulator data indicates that the flight time 
response was relatively good, but there were some 
differences. At BCS transfer, the simulator initial 
pitch was down as compared to up for flight. The 
large nose up command in the simulation data oc- 
curred about 11.5 sec after transfer to BCS as com- 
pared to 9 sec for flight. The nose up time response 
for both the simulator and flight were in good agree- 
ment, while the following nose down simulator re- 
sponse was larger in amplitude than in flight, as was 
the subsiding motion. Elevon response through the 
dynamic or transonic portion of the response showed 
relatively poor agreement with flight. The simulator 
elevon response at supersonic and subsonic speeds 
(the initial and final portion of figure 48), although 
biased, was comparable with flight data. The dif- 
ferences between simulator and flight data can be 
attributed to transonic aerodynamic modeling er- 
rors in the simulator data. This problem could have 
been eliminated in the BCS if the transonic static 
pressure error inverse had been mechanized as part 
of the control law. 
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CONCLUDING REMARKS 

The HiMAT program was successfully completed in 
1983 with a total of 26 flights on two vehicles and 
approximately 11 hr of total flight time. All pro- 
grammatic and design goals were either achieved 
or exceeded. These included a sustained 8-g turn 
at Mach 0.9 and 25,000 ft altitude and a sustained 
straight and level dash to Mach 1.4. 

The requirement that no single failure result 
in loss of the vehicle dictated a complex approach 
to the development of all flight systems. Virtually 
all HiMAT systems were dualized and fully flight 
qualified. Few failures occurred in flight and none 
were serious enough to threaten loss of a vehicle. A 
single decoder failure resulted in a transfer to the 
backup flight control system and brought about the 
only landing with this system. 


Each of the flight control systems and associ- 
ated subsystems performed exceptionally well over 
the course of the program. Hard failures of ground 
systems were nonexistent and only a few airborne 
systems failed. Not a single ground or airborne com- 
puter failed during a flight, and each control system 
performed as specified. 

Inclusion of a flight test maneuver autopilot en- 
hanced the acquisition of high-quality flight data 
and holds great promise for future applications in 
both manned and unmanned aircraft. 


Ames Research Center 
Dryden Flight Research Facility 
National Aeronautics and Space Administration 
Edwards , California , June 11, 1987 
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TABLE 1— HiMAT PRIMARY AND BACKUP CONTROL SURFACE AUTHORITIES, 
ANGULAR RATES, AND CONTROL SYSTEM FUNCTION 


Control 

surface 

Control 

mode 

Angular 
surface rate, 
deg/sec 

Maximum 
surface authority, 
deg 

Surface function 

Primary control Backup control 

Elevator 

Primary 

76.6 

+28 to -21 

Symmetric pitch control 

Locked at +2.5° 

Elevon 

Primary 

87.2 

+27.5 to -20 

Symmetric pitch and 

Symmetric pitch and 





asymmetric roll control 

asymmetric roll control 


Backup 

86.9 




Rudder 

Primary 

65.6 

±10 

Yaw control and 

Yaw control 


Backup 

64 


speed brake 


Aileron 

Primary 

86.8 

±20 

Roll control 

Locked at 0° 

Canard 

Primary 

87.3 

+ 18 to -20 

Symmetric pitch and 

Locked at 0° 


asymmetric roll control 


TABLE 2— HiMAT PILOT’S GROUND COCKPIT STICK AND 
RUDDER PEDAL CHARACTERISTICS 


Pilot’s 

control 

Airplane 

axis 

Break-out 
force, lb 

Force 
gradient, 
lb /in 

Displacement, 

in 

Stick 

Pitch 

3.5 

3.92 

5 aft, 6 forward 


Roll 

1.0 

3.71 

±4.25 

Rudder pedal 

Yaw 

8.5 

8.5 

±3.25 


TABLE 3— HiMAT GROUND-BASED COMPUTERS’ 
FUNCTIONS AND CHARACTERISTICS 


Computer 

Characteristics 

Functions 

V-73A 

Hardware floating-point 

Primary control laws 


32K 16-bit memory 

Cockpit display 


Full set of peripherals 

computation 


Real-time FORTRAN 

Preflight test 
Fault detection 

V-73B 


Maneuver autopilot 
control law 

Transfer guidance data 
to cockpit 

V-77 

32K 16-bit memory 

Telemetry interface with 


Limited peripherals 

V-73 computer 


Slower than the V-73 

Caution- warning display 

V-72 

Same as V-77 

Navigation and ILS 
computation from 
tracking radar 
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TABLE 4 — HiMAT ONBOARD 
SYSTEMS AND HARDWARE 
FAILURES WHICH CAUSE 
AUTOMATIC TRANSFER 
TO BACKUP CONTROL 

Sensed failure 
Decoder number 1 
Decoder number 2 
Primary electrical system 
Primary hydraulic system 
Simplex actuator: 

elevator, aileron, or canard 
Primary computer 
Uplink system 
Downlink system 


TABLE 5- 

HiMAT BACKUP FLIGHT CONTROL SYSTEM MODES AND MODE 
FUNCTIONAL CHARACTERISTICS 
(a) Recovery, Orbit, Straight and Level, and Turn Modes 

Mode 

Mode function 

Recovery 

BCS initialized in this mode 

Brings the vehicle to level flight (altitude rate - 0) 

Reduces airspeed to subsonic Mach numbers 
Provides inverted recovery if altitude rate is above 12,000 ft /min 
External discrete commands not honored until altitude rate is ±600 ft /min 
Will reenter recovery mode if Mach number exceeds 0.96 or if altitude rate 
exceeds 12,000 ft /min 

Orbit 

Orbit mode will be entered at expiration of 25-second timer following transfer 
to BCS unless orbit has been deselected 
Vehicle will climb to one of three orbit altitudes or dive to 25,000 ft if BCS 
entered above this altitude 
Orbit altitudes are 25,000 ft, 10,000 ft and 5,000 ft 
Bank angles are 35° above 4,000 ft and 20° below 
Left or right orbits are pilot selectable 

Straight and level 

Altitude, quasi-heading, and speed or Mach hold M « 0.8 above 20,000 ft 
and V c & 300 knots below 

Turn 

Attitude command with a roll rate of 20 deg/sec to ±35° bank 
angle above 4,000 ft and ±20° below 
Roll rate command mode roll rate is 15 deg/sec with no bank angle limit 
Automatic turn rate commanded as a function of airspeed 


27 



TABLE 5— COMPLETED 

(b) Climb-Dive, Land, and Engine Out Glide and Flare Modes 

Mode 

Mode function 

Climb-dive 

All climbs at 100 ft /sec 

Dives above 10,000 ft at 100 ft/sec and dives below at 60 ft/sec 

Land 

Scheduled airspeed and altitude rate command as a function of 
radar altitude 

Pilot modulation of airspeed and altitude rate within limits; 

minimum airspeed is 185 knots 
Maximum radar altitude is 5000 ft 
Alternate land mode provided if radar altimeter failed 
Pilot can select roll rate command for precise heading control 

Engine out 

Commanded airspeed of 215 knots with modulation capability 
Flare initiated at 550 ft radar altitude when elevon control transfers from 
airspeed command to altitude rate command for the flare; the initial altitude 
rate for the flare was the existing rate at 550 ft; commanded altitude 
was then ramped to -5 ft/sec at 25 ft 


TABLE 6— HiMAT AIRBORNE INTEGRATED PROPULSION CONTROL 
SYSTEM COMMAND AND FEEDBACK FUNCTIONS 


Function 

Onboard computer control mode 
Backup/PCS Primary/BCS 

Command function 

Power lever angle 

X 

X 

Variable nozzle area 

X 

X 

Engine igniter 

X 


Throttle feedback select signal 

X 


Variable nozzle area override 

X 

X 

Feedback function 

Compressor inlet total pressure 

X 

X 

Compressor discharge total pressure 

X 

X 

Turbine discharge static pressure 

X 


Turbine discharge temperature (EGT) 

X 

X 

Rotor speed (rpm) 

X 


Main fuel control throttle position 

X 

X 

Exhaust nozzle area 

X 
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TABLE 7— HiMAT RELAXED STATIC STABILITY PRIMARY FLIGHT CONTROL SYSTEM 
GAINS, SCHEDULES, AND FILTER DESCRIPTIONS 
(a) Normal Controller and Alpha Limiter 


Symbol 

Name 

Value-function-comments 

Units 

Normal controller 

KNA 

Alpha gain 

0.0 for M < 1.0 

deg/deg 



-5.0 for M > 1.0 


KNQ 

Pitch rate gain 

0.5 

deg/deg/sec 

KNNZ 

Normal acceleration gain 

4.3 

deg/g 

KND 

Longitudinal stick command gain -11.25; for landing -7.5 

deg/in 

LDEP 

Launch stick command 

-0.75 

fades to zero after 3 sec 

in 

DEP 

Pilot’s stick command 

DEPOUT 

in 



= DEPIN {ESLOPE 
+ [(1 - ESLOPE)/4.5]|DEPIN|} 


ESLOPE 

Nonlinear parameter 

0.4 


KNT 

Total controller gain 

(0.46 - 0.0004 *q) for q < 400 lb/ft 2 
0.30 for q > 400 lb/ft 2 

deg/ deg 

KPMPC 

Variable test gain 

Pilot-selectable gain for test 
0 to 0.7 


Alpha limiter 

KALM 

Positive alpha limit 

12.0° for M < 0.8 

0.8 < M < 0.9, 12 + 30 * (M - 0.8) 
15.0° for M > 0.9 

deg 

KAA 

KAQ 

Alpha gain 
Pitch rate gain 

1.26 

0.1875 + 150/g for q > 100 
1.6875 for q < 100 

deg/deg 

deg/deg/sec 

KLA 

Negative alpha limit 
Negative alpha gain 

-3° 

1.26 

deg /deg 


TABLE 7 — Continued 

(b) Normal Acceleration Limiter and Onboard Pitch Rate Loop 


Symbol 

Name 

Value-function-comments 

Units 


Normal acceleration limiter 


KGLM 

Normal g limit 

10 g 


KGNZ 

Normal g gain 

103.14/g for q > 100 lb/ft 2 
1.0314 for q < 100 lb/ft 2 

deg/g 

KGQ 

Pitch rate gain 

3.51 /q for q > 100 lb/ft 2 
0.351 for q < 100 lb/ft 2 

deg/deg/sec 


Onboard pitch rate loop 


KBQ Pitch rate gain 0.25 deg/deg/sec 

In degraded primary = 0.50 
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TABLE 7 — Continued 
(c) Roll and Yaw Axes 


Symbol 

Name 

Value-function-comments 

Units 


Roll 

axis 


KRP 

Roll rate gain 

-60 /q for M < 1.0 

deg/deg/sec 



-120 /q for M > 1.0 


KRD 

Lateral stick command gain 

I8OO/9 for M < 1.0 

deg/in 



3600/9 for M > 1.0 




4.0 for landing 


KRMCP 

Variable test gain 

Pilot select for test 0 to 0.9 


KARI 

Aileron-to-rudder-interconnect 

-0.5[(0.00933)alpha+0.015] 

deg/deg 


Yaw 

axis 


KYAY 

Lateral acceleration gain 

1489.8/9 for q < 744.9 lb/in 2 

deg/g 



2.0 for 9 > 744.9 lb/in 2 


KYR 

Yaw rate gain 

35/9 

deg/ deg /sec 



(35.0)M/9 for M > 1.0 


KYD 

Rudder pedal command gain 

0.858 

deg/in 

KYMCP 

Variable test gain 

Pilot select for test; 0 to 0.9 



TABLE 7 — Continued 
(d) Default System Gains 


Symbol 

Name 

Value and units 

Normal controller 

KNA 

Alpha gain 

0 

KNQ 

Pitch rate gain 

0.5 deg/deg/sec 

KNNZ 

Normal acceleration gain 

4.3 deg/g 

KND 

Longitudinal stick 

-11.25 deg/in 


command gain 


KNT 

Total controller 

0.414 deg/deg 

Alpha limiter 

KALM 

Positive alpha limit 

12° 

KAA 

Alpha gain 

1.26 deg/deg 

KAQ 

Pitch rate gain 

1.50 deg/deg/sec 

KLA 

Negative alpha gain 

1.26 deg/deg 

Normal acceleration limiter 

KLGM 

Normal g limit 

10 g 

KGNZ 

Normal g gain 

0.906 deg/g 

KGQ 

Pitch rate gain 

0.03078 deg/deg/sec 

Roll axis 

KRP 

Roll rate gain 

-0.526 deg/deg/sec 

KRD 

Lateral stick 

4.0 deg/in 


command gain 


Yaw axis 

KYAY 

Lateral acceleration gain 

13.06 deg/g 

KYR 

Yaw rate gain 

0.307 deg/deg/sec 

KYD 

Rudder pedal 

0.858 deg/in 


command gain 



TABLE 7 — Concluded 
(e) Systems Filter Representations* 


Filter 

Type 

Transfer function 

identification 


Normal controller 

PN01 

High pass 

s/(s + 5.0) 

PN02 

Low pass 

1/0/15 + 1) 

PN03 

Low pass 

1/0/15 + 1) 


Alpha 

limiter 

PA01 

Lead-lag 

0/10+ l)/0/5+ 1) 

PA02 

Lead-lag 

O/10+l)/O/2.5+l) 

PA03 

Lead-lag 

0/15+ 1)/0/60+ 1) 

PA04 

High pass 

•s/0 + 5.0) 

PL01 

Lead-lag 

0/10+l)/0/5+l) 

Normal acceleration limiter 

PG01 

Lead-lag 

(0.82755+ l)/(0.2s + 1) 

PG02 

High pass 

s/^sj 30 + 1) 

Pitch integrator 

P01 

Integrator 

5/s 


Roll 

axis 

R01 

Low pass 

1/0/5 +1) 


Yaw 

axis 

Y01 

high pass 

5 /0 + !) 

Y02 

Low pass 

1/0/5 +1) 

Y03 

Low pass 

20/0 + 20) 


* All filters are presented in continuous s-plane rep- 
resentation. Filters were transformed to digital form 
using Tustin’s method. 


TABLE 8— HiMAT GROUND COMPUTER 


FAILURE DETECTION AND ANNUNCIATION 

Fault category 

Cockpit 

annunciation 

indication 

Downlink integrity 
Uplink integrity 
Real-time loop integrity 
Computer watch-dog timer 
Stick input checks 
DAC/ADC wrap tests 
Air data miscompare 
Angle-of-attack miscompare 

Input-output fail 
Input-output fail 
Computer fail 
Computer fail 
Stick fail 
Stick fail 
Air data fail 
Angle-of-attack fail 


TABLE 9— HiMAT ONBOARD FAILURE CONSEQUENCES AND 
MISSION IMPACT ANNUNCIATION OF SYSTEMS’ CONDITIONS 

Automatic transfer to backup failure 

Mission abort annunciation 

Primary hydraulic system 
Primary electrical system 
Duplex actuator (primary side) 
Simplex actuator 
Primary computer downlink or 
uplink 

Primary computer power 
monitor 

Primary computer 

Backup computer uplink fail 
Intercom failure 
Engine fire-overheat 
Engine flameout 
IPCS sensor fail 
Low-fuel warning 
Engine shutdown command 
Battery on line fail 
Avionics temperature high 


Inhibit auto, transfer to backup failure 

Caution condition annunciation 

Backup hydraulic system 
Duplex actuator (secondary side) 
Backup sensors (no. 3 unit) 
Backup computer real-time 
clock 

Backup computer power 
monitor 

Backup computer 

Primary sensor fail 
Radar altimeter fail 
Attitude gyro fail 
Primary duplex actuator fail 
Backup 28-V power on fail 
Decoder unreliable 
Generator voltage alert 
Uplink discrete differences 



TABLE 10— HiMAT CENTER OF GRAVITY AND STATIC MARGINS 
FOR THE RELAXED STATIC STABILITY CONFIGURATION 
IN THE LANDING APPROACH FLIGHT CONDITION 
(Center-of-gravity location with respect to the 
reference center-of-gravity location at 
fuselage reference station is 134.26) 



Landing gear up 

Landing gear down 


Center-of-gravity 


Center-of-gravity 


Case 

location, 

Static margin, 

location, 

Static margin, 


percent chord 

percent chord 

percent chord 

percent chord 

Forward c.g. 

7.0 

12.23 

8.1 

12.83 

Aft c.g. 

5.2 

0.06 

4.2 

0.58 


TABLE 11— MAXIMUM ANGULAR 
SURFACE RATES ACHIEVED 
IN EXAMPLE TIME INTERVAL 


Surface angular 
rate, deg/sec 

Forward 

c.g. 

Aft 

c.g. 

8 Tl 

+ 1.5 

+5.0 


-1.0 

-7.0 

8y L 

+9.0 

+ 12.0 


-6.0 

-10.0 

ZL 

+6.0 

+9.5 


-7.5 

-5.0 
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Figure 1 . Three-view drawing of 
HiMAT vehicle . 
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Figure 2. HiMAT vehicle control surfaces . 
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(b) Pilot’s left console. 
f. HiMAT around-based RPRV 
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Figure 6. Major components of the HiMAT airborne flight systems. 
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Figure 7 . Airborne computer- aircraft systems interface diagram. 
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Figure 8. HiMAT stable PCS longitudinal control law . 
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Figure 9. Stable PCS roll-yaw axis control laws . 
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Figure 10. Throttle control law. 
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Figure 11. Speed-brake control law . 
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Figure 12. HiMAT time delays from airborne sensors to surface commands and 
mechanization of onboard pitch rate feedback . 
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Angie-of-attack limiter 
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Figure 14 • HiMAT relaxed static stability , 
primary flight control system angle-of- 
attack limiter limits . 



Figure 15. HiMAT ground-based relaxed static stability lateral- directional primary 
flight control system . 
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Figure 17 . BCS longitudinal recovery-mode command loop . 



Figure 18 . BCS longitudinal command modes 
















Figure 19. BCS lateral- directional control laws. 
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Figure 20. BCS throttle control law. 
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Figure 21. 


HxMAT systems failure- detection hierarchy. 
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Figure 22. HiMAT master caution- warning (MCW) panel. 
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Figure 25 



7195 


CASH simulation 





Figure 26. HiMAT iron bird simulation. 
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Figure 27. HiMAT configuration control process. 


53 























Angle of 
sideslip, 
deg 


Yaw rate, 
deg/sec 




(b) l 

Figure 





8 

Time, sec 


der inputs . 

. Concluded . 













Yaw rate, 
deg /sec 






Figure 33. HiMAT lateral- directional oscillation induced by engine vibration being 
aliased through the lateral accelerometer to the rudder . M = 0.72 , h = 40,000 ft. 
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Figure 3 4 , HiMAT transonic pitch-up through the angle- of- attack limiter. 0.85 < 
M < 0.90 , 26,000 ft < h < 27,100 ft. 
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Figure 35. HiMAT landing gear extension transient comparison between forward and 
aft center- of- gravity location. 
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(a) Forward center- of- gravity location. 

Figure 37. HiMAT left control surface position angular rates at landing 
gear extension. 
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(a) Left rudder . 

Figure 38. HiMAT control surface 
probability distribution using 4AOO data 
points for a 20-sec time interval. 
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Figure 38. Continued. 
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(c) Left elevon. 
Figure 38. Concluded. 
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Figure 39. Comparison of three FTMAP- 
flown windup turns at nominal conditions of 
Mach 0.90 and 25,000-ft altitude. 
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Figure 40. Comparison of two pilot-flown 
windup turns at nominal conditions of 
Mach 0.90 and 25,000-ft altitude. 
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(a) Mach number — 0.65, h = 26,000 ft, 
q — 220 lb/ ft 2 , V c — 260 knots. 

Figure 41 . HiMAT transfer from primary 
control to backup control, recovery mode. 


69 


I 


Pitch rate, 
deg/sec 



Load 

factor, 

9 



T — ~1 


Elevator 

position, 

deg 



Symmetric 

elevon 

position, 

deg 



Altitude 

rate, 

ft/min 



Bank 

50 

angle, 

0 

deg 

-50 

-100 

30 

Roll rate, 

20 

deg/sec 

10 

0 

-10 

6 

Differential 

4 

elevon 2 

position, 

deg 

U 

-2 

0 

Rudder 

position, 

-10 

deg 


-20 

0 

Yaw rate, 

-1 

deg/sec 

-2 

-3 




J! I I I L 


A 






J I L 


2 4 6 8 10 12 14 

Time, sec 


(b) Mach number =r 0,85 , h — 25,450 ft, 
q - 390 lb /ft 2 , V c = 360 knots. 

Figure 41 • Continued. 
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Figure 1^2. HiMAT backup control , orbit 
mode Mach number = 0.82, h = 25,400 ft, 
q — 360 lb /ft 2 , V c = 343 knots. 
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(a) Attitude command , Mach number = 
0.82, h = 24,900 ft, q = 373 lb/ft 2 , V c = 
348 knots . 

Figure 44 • HiMAT backup control , turn 
mode . 
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(c) Roll-rate command, Mach number = O. 4 I , h = 5,200 ft, q — 202 lb/ft 4 
V c = 240 knots . 


Figure 44 - Concluded . 
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(a) Mach number = 0.82, h — 

25,800 ft, q = 350 lb /ft 2 , V c = 
337 knots. 

Figure 1^5. HiMAT transfer from 
backup control to primary control. 
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(b) Mach number = 0.80, h = 26,900 ft, 
q = 325 lb /ft 2 , V c = 325 knots. 

Figure 1,5. Concluded. 
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Figure 1^6. HiMj 
mode landing; LA 
h ~ 2,950 ft. 
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